OSDev.org

rdos wrote:

bluemoon wrote:Some system uses ACL as key for "one-way" decryption, unless you have a supercomputer to crack it.

Might be so, but the users lists probably is in an ordinary file. If the ACL-less OS knows about the ACL-using OS ways of handling these ACL, it could simulate everything, including user login, and just discard any restrictions setup. Unless the file contents use keys that include the passwords, but then you cannot change passwords without recrypting file contents.

It would be really nice to have a couple of these ACL-using filesystems in RDOS, and just multiboot to be able to read anything without restrictions.

How about ACL(user id) + (user password or USB security device or external security token) as decryption key?

brain wrote:while on the subject of cleanup tools, beware of some things regarding reiser, at least version 3.

I used reiser 3 for quite some time on linux and i never will use it or any later version ever again. My friends told me it was amazing in performance and reliable etc. Well one day my system powered off unexpectedly due to power failure and upon powering back up i had a software disk error, e.g. corrupted filesystem.

So i ran fsck on the disk and it gave up 40 minutes later, saying something like:

fsck.reiser cant fix this disk. only a certain subset of errors in the inode tree can be fixed. if you want to you can call our premium support line on <blah> which is charged at $3 per minute.

Needless to say, i went to my backup cursing reiser and never ever used it again.

If you are implementing it, be aware of these reliability issues and code a BETTER recovery tool!!!

That is a personal experience, I know i've used Reiser plenty of times but it doesn't fit the profile of what one wants for a NFS system.
Reiser is perfect when you have thousands of small files.
I would cache a file index in RAM and check which files system has a low latency and high through put.

rdos wrote:I would prefer a FS that never needs recovery, regardless of when I turn-off my computer.

That's called soft-update. See http://en.wikipedia.org/wiki/Soft_updates

As for the OP: why don't you design your own fs? Isn't this OS writing is all about? Rolling your own?
I did not find any fs that would meet my needs, so I've designed my own, here's a brief list of features:
- unlimited storage capacity (several million yotabytes, up to 2^330 bytes)
- unlimited file size (with 4096 sector size 2^76 bytes, up to 2^128 bytes)
- unlimited number of files and directories, dynamic inode allocation
- scales really well (random access in a 1MiB file requires 1 plus sector read, in 8TiB only 4 plus reads)
- very small footprint (fs meta info requires averagely less than 5%, but scales in inverse ratio to storage size)
- data integrity (system blocks have internal checksums, data sectors external)
- resistant to fragmentation (random access in a new file is the same as in a file that modified thousand times)
- per file snapshots, recoverable history up to 6 versions
- copy on write allocation for each version
- supports extended file information (key+value database in BSON format)*
- directory entries are fixed in size and ordered, ideal for fast logarithmic search
- consistent directory hierarchy (made after FHS)
- stores mime type of content along with file
- encryption support*
- mixes win, unix and vms style paths
- disk pool and RAID support*
- clear soft-update api
(* not fully implemented yet, only partial support)

rdos wrote:What exactly is the point of ACLs if you can multiboot the machine with an OS that supports the FS but not the ACLs?

The general understanding of system security is that, if a person has control of the boot sequence, there is nothing you can do to keep your system secure.

You should know that.

Solar wrote:

rdos wrote:What exactly is the point of ACLs if you can multiboot the machine with an OS that supports the FS but not the ACLs?

The general understanding of system security is that, if a person has control of the boot sequence, there is nothing you can do to keep your system secure.

You should know that.

To get control of the boot process all you need to do is to load a bootable CD/DVD/floppy, and possibly change BIOS to make it boot. If FS security was simply this, why bother with requiring users to authenticate?

The ACLs are supposed to be set in the firmware.
Would you like any more features?

rdos wrote:

Solar wrote:The general understanding of system security is that, if a person has control of the boot sequence, there is nothing you can do to keep your system secure.

You should know that.

To get control of the boot process all you need to do is to load a bootable CD/DVD/floppy, and possibly change BIOS to make it boot. If FS security was simply this, why bother with requiring users to authenticate?

Alas, it appears you don't know.

No file system feature whatsoever can reliably prevent a system from being hacked by someone who has physical access to a system.

That's a generally accepted fact of system security design, and the reason why stuff like locked server rooms and Intrusion Detection exist.

UEFI's secure boot is trying to prevent this however, by making it a requirement for everything to be cryptographically signed. In a perfect world, it would work. Unfortunately, the UEFI spec is ~2200 pages long, and there's bound to be a bug in there somewhere.

As for as file systems worth implementing for a NAS system, today I watched a conference presentation by one of the folks developing btrfs, which looks really cool. It would most likely be a tonne of implementation work, but it supports a huge featureset: different RAID levels for different individual files, copy-on-write, subvolumes, and much more. Worth looking into using some of the feature ideas, at the very least.

JackScott wrote:...
In a perfect world, it would work. ...

If a firmware rootkit has installed itself on your board, no number of signed checks can stop it from rooting your system. It's a firmware rootkit. Even if somehow the signing and everything were impenetrable (they most certainly are not), the very first SMI would invalidate all of that "chain of trust" mess and...root the system. Secure boot is nonsense.

Firmware rootkits are highly specific and are used in very sohpisticated attacks on chosen targets. A general purpose OS like Windows has no business trying to weasel itself in there acting like it has relevance somewhere in the fray. For example, where does windows' secure boot fit into the Stuxnet attacks on Iran? And if they had been using Windows on the machines, and Secure boot was implemented back then, what difference would it have made? None. Stuxnet was a highly specific firmware rootkit. I don't know if MS has changed their approach to promoting it, but they seemed to be using that "firmware rootkit" buzzword a lot at first.