OSDev.org

Hi,

Kevin wrote:

Brendan wrote:For a related example, consider UEFI. It uses FAT for an "EFI system partition", which means that any idiot (using almost any OS) can screw up anything in the "EFI system partition" (either accidentally or maliciously). There's no sane/easy way to guard against that, and you'd probably have to resort to something extreme (like requiring digitally signed executables) just to solve some of the security problems (where "some" doesn't include DoS).

So you're arguing for security by obscurity? Just use a file system that no OS implements (yet) and everything magically becomes secure?

I'm not arguing for security by obscurity, I'm simply arguing against a file system where any random idiot using any OS (regardless of how secure the OS is) can trash anything they like. How about using a file system that supports "user identifiers" (e.g. the UIDs that Unix had 4 decades ago), where EFI (and decent/secure OSs) honour those UIDs, so that it's actually possible to prevent random idiots from deleting your boot loader without providing a password of any kind? If someone installs an insecure OS that doesn't honour the file permissions, then that's the user's fault for installing an insecure OS.


Cheers,

Brendan

Well, on any reasonbly secure OS, why would a random user be able to mount the file system on this partition or, even worse, have direct access to the block device?

Having EFI honor UID's would mean that EFI would have to administrate a list of users and their IDs, and all OS's running on the machine agreeing to that UID list.

Brendan wrote:If someone installs an insecure OS that doesn't honour the file permissions, then that's the user's fault for installing an insecure OS.

Whether you honor UIDs or you disallow that particular partition from mounting (without admin privileges) is a matter of the OS either way. The EFI honoring UIDs isn't the way to solve this particular problem. FAT - for which every OS has a driver readily available - isn't a half-bad design decision here.

To the malicious user, having physical access to a machine is generally the best way to void the majority of security practices. The net result of that observation means that for the stupid user, the only thing you can do is nothing more than making the practice of screwing up difficult.

In the end, DRM is little more than a method of making things difficult.

EDIT:
And as far as FAT is concerned, if you design your OS on top of FAT (or any filesystem for that matter), you are doing it wrong. You should instead design interfaces for the userspace-visible features of the system. After your interface is done, you go implement the file system on your test medium because it is the first FS you will actually use. And for the majority of people here that's either FAT or ISO9660.
The second reason is that neither will be able to provide all the features of your filesystem design so you immediately test your design by finding out how to deal with everything else you will be guaranteed and doesn't adhere to your ideals.

It also shows that of all the points mentioned, metadata logging, inodes and special files/mount points are a wrong choice for the actual on-disk format of the filesystem: Inodes are an implementation detail and are not practically referenced by number, logging happens completely agnostic to userland software, and device files and mount points belong in the average VFS layer and not in the filesystem.

In other words, the only real feature left to care about are ACLs. The rest qualifies as "work in progress" which is strictly unrelated to being "modern", and which is why Brendan's blanket statement is little more than an idealized one. And that's not considering embedded systems and their kin for which all the "nice features" are little more than waste and FAT may actually be the best choice.