How safe is FSLock on 5.21?

Hi,

Sounds like a possibly odd question but:

How safe is FSLock on the current systems (testing stuff on a Pi at the moment).

ie. if you set FSLock:
1) Does it work?
2) What is the likely risk of screwing up my disc image – never to be used again?

You may establish from this that I am NOT asking whether actually using it is a good idea or not – just ’what’s the worst that can happen’???
(posted in ‘code review’ as this is more directed at a ‘feature/code stability’ question rather than general usage).

How safe is FSLock on the current systems (testing stuff on a Pi at the moment).

…fancy being a guinea pig? ;-)

1) Does it work?
2) What is the likely risk of screwing up my disc image – never to be used again?

In reverse order – once you have a nicely set up image of RISC OS and all the gubbins installed in the places you want them and a configuration you are happy with…
…that’s the time to take an image of your entire SD card and clone it to another. That way, if a firmware or OS update goes wrong or a power cut screws up your SD card, you can get going again with minimal disturbance.

Secondly – FSLock “protects” drives 4-7 of any specific filing system. It does this by trapping writes (except for Scrap and Public) and returning an error. It doesn’t read-protect, nor does it encrypt.

It is, I note, likely to be utterly useless on a Pi.
(edit: see below)

I base this harsh judgement on the fact that the text below the SD card says :0 and the text below the USB stick also says :0.

Quick test… Uh-hu… “Protects” SDFS, fails to write protect.

Okay. I have made a hack to the FSLock module to look at drives 0-3. The module identifies itself with the suffix “, Rick’s hack#19:50” on the version string (19:50 being the time according to my Pi which is, like, two timezones incorrect ;-) ).

The module itself is here → http://www.heyrick.co.uk/random/fslock/FSLock,ffa

It isn’t terribly useful to you as the FSLock module cannot be killed.

Therefore, a RaspberryPi ROM image is here → http://www.heyrick.co.uk/random/fslock/MYROM.IMG

It identifies itself as today’s because it was compiled today, however in reality it is v5.21 from circa 4th November. I don’t think I have modified/broken anything else in this particular image. It does work on a Pi (I’m running it right now). If you feel brave, copy this to the FAT part of your SD card and amend the CONFIG.TXT to point to it. That ought to be all it needs. You will need to call it “riscos.img” (DOS name style).

For what it is worth, the modified source code is here → http://www.heyrick.co.uk/random/fslock/FSLockSRC,ffb and you can spot my mods by looking for “[Rick”.
If I have some free time, I will have a look to see if I can get the code to pick up on the environment so it will build a module to protect drives :4 to :7 on IOMD/Iyonix and drives 0: to :3 on anything else.
I can’t just hack the code to protect :0 to :7 on everything because this runs the risk of nobbling floppy discs on older hardware if it is ADFS being “protected”.

Oh, and remember, you need to “unlock” it twice to turn this off. The first unlock is “temporary”, the second disables FSLock.

Mmm… The module works. Whatever it tries to set in CMOS is not carried between sessions. If you lock on a Pi and reboot, it comes back as “unlocked”.

How is “CMOS RAM” handled on the Pi? If it helps, I have a CJE RTC module; though I’m not sure where in the code I ought to be looking to find the answer to this!

Answer: Needs to be called “riscos.img”, and CMOS is dealt with by …cddl.RiscOS.Sources.HWSupport.SD.SDCMOS.s.sdcmos.

Aha – found it.

The SDCMOS module is hardwired to SDFS::0.$.!Boot.Loader.riscos/img so it will only work if that’s what your installation is called.
Oooh boy. Had to reconfigure everything. Still, picked a better backdrop and I like the “Rain” screensaver. ;-)

Caveat – of course, with FSLock and SDCMOS both working, it makes it “interesting” trying to undo the File/CMOS protection when the File/CMOS protection is protecting the File/CMOS protection from being written. It isn’t insurmountable, but it is… quirky.

I might add “$.!Boot.Loader” to the exclusion list. While it exposes a potential weakness, turning the protection on and off is a bit… troublesome… otherwise; and besides, inserting said SD card into anything that understands FAT volumes will allow unfettered access to said data.
RFC?

Rick: “Fancy being a guinea pig?” – Not yet! Absolutely not – that’s why I wondered whether anyone else had offered up an SD card for potential irreversible corruption! I have also installed an RTC – so was a bit concerned in case that saved stuff to CMOS…I predicted any manner of complete nastiness that could result from an errant FSLock assuming it still happily lived in RISC PC land.

I haven’t yet cloned my SD card. I had assumed !CloneDisc was going to be the tool for exactly that – but it appears it doesn’t do copies of SDFS:0 to SDFS:0 (start button remains grey) – which is a shame as I have two SD cards ready to go.

Rick: I suspect we would be wiser removing FSLock as a feature from the OS entirely, and then building in something which uses the inbuilt encryption/security standards on the actual devices being accessed. I remember that both SCSI and ATA had quite advanced security sets; I don’t really know the ones for more modern systems but the assumption is that this technology is improving not deteriorating!

If we could find a way of abstracting that security to become standardised – it would offer us security that applied across-platforms.

I wondered whether anyone else had offered up an SD card for potential irreversible corruption!

No, your card won’t be corrupted. FSLock works at a higher level than that, trapping file operations and erroring ones that do writing activities.

I have also installed an RTC – so was a bit concerned in case that saved stuff to CMOS

It writes the password to “CMOS”, which in this case is the end of the ROM image (assuming you name it correctly!). Frankly, life would be a lot simpler if it all wrote to real CMOS, but I think the CJE thingy only has around ~60 bytes onboard…

I predicted any manner of complete nastiness that could result from an errant FSLock assuming it still happily lived in RISC PC land.

;-) Such as the assumption that drives of interesting count from :4?

Actually, it seems to do its job, insofar as it is possible when it is protecting its own ROM image file!

It appears that the system starts in a lower resolution display when FSLock is active. Not tracked down why, yet.
Ran FSLock on a live system. Protected SDFS :0 and copied out a bunch of settings files to a RAM disc (that part is kind of clever).

To remove FSLock protection, follow these steps:

1. Open Configure (double-click on !Boot) and click the only thing you can – the Lock icon.
2. Select “Unlock” and enter the correct password.
3. Open a TaskWindow and go to BASIC.
4. Enter CLOSE#255 and press Return. You’re done with the TaskWindow afterwards.
5. Click on the Lock icon again and select “Unlock” again and enter the correct password again.
6. Done.

The file close is because the DOS partition is opened read-only when locking is active, so you need to force it to be reopened read/write, otherwise things that write to CMOS RAM will return “File is not open for update” errors, and you’ll never be able to turn off FSLock.
It’s not a hard workaround, just not an immediately obvious one. ;-)

but it appears it doesn’t do copies of SDFS:0 to SDFS:0

Makes sense – there isn’t enough RAM onboard to store a dump of an SD card, which leaves either requiring a third device to act as a cache, or a lot of disc swapping that might not even be possible (depends on how SD cards ‘mount’ themselves).

Do you have a PC? I use WinDiskImager (or something with a name like that) to rip card images to harddisc, then dump back out to a new card in one tidy go…

I suspect we would be wiser removing FSLock as a feature from the OS entirely, and then building in something which uses the inbuilt encryption/security standards on the actual devices being accessed

Hmmm… I guess this depends upon what level of “security” you expect in RISC OS. I am not a member of Anonymous nor a Wikileaks member, so I don’t have anything worth encrypting. Basic write-protection is good enough for me. Remember, RISC OS is not a secure OS.

Proof? Waaaaaay back in the day (like, The Dark Ages), I wrote a small module to notice Econet logins (I think I looked for Lib changing, don’t remember) but it worked “after the fact” because I worked through NetFiler’s memory to discover the location of the templates data, and then wrote some code to just read the username/password out of the icons of the (closed) window. ;-) Said password would then be *Notify’d to me. There might have been an easier way, but it worked.

Not that it mattered, if you had physical access to a FileStore you could format a blank floppy in Maintenance Mode, log in as SYST, create a user with a name that doesn’t already exist in the system, make it an admin, then reboot with both your custom floppy in use and the class floppy now inserted. Log in as your admin user on the custom floppy to swap over and make yourself an admin user on the class floppy. Once you are logged in as a PRIVed user, you have PRIVs. Everywhere.
[compared to that, getting anything useful from an MDFS was a nightmare!]

Rick: If I were a member of either of the above, I’d be arguing NOT to use the built-in security in case it had backdoors :-). Don’t need FSLock for write protection on SDFS – there’s a little tab for that :-).

I too have fond memories of waiting until our IT teacher had logged in on the A3020 – to then do a quick *MemoryI and retrieve the unencrypted admin password for later use :-).

Don’t need FSLock for write protection on SDFS – there’s a little tab for that :-).

AIUI On some systems the write protect tab can be read but it is then up to the software to obey it and not all do. On the Raspberry Pi the write protect switch in the holder isn’t even wired up!