Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Operating Systems

Journal cyclomedia's Journal: Suggested new OS FS permissions/security model 1

Being a web developer I'm used to having my sites live in virtual server directories. The basic permissions of which are set by the administrator (read/write/execute) etc. But the fundamental restriction in place by default is one where i cannot write or modify a file anywhere above my virtual root directory. regardless of it's physical location on the server.

this imposed glass ceiling could be stretched to program permissions across an OS. Imagine a mail client called Origami Email (OE) (c:\programs\oe) that had a vulnerability exploited by a malicious email. the best the incoming worm could hope to achieve is the modification of the files in the directory it resides (c:\programs\oe\emails) or any sub directories (c:\programs\oe\emails\archive) but not it's parent or an adjoining branch. i.e. the OS core and other programs would be wholly inaccessible to it. all that needs to be done is to have the file system know where the code accessing it originates and act accordingly.

Issues are now raised when it comes to usability, if PhotoEdit lives in c:\programs\photoedit it wont be able to get to c:\documents to open or save photos! So the default permissions would set c:\documents to a DMZ (enabling aforementioned worm to stomp all over it if it wished, obviously) and applications could have run-time set permissions much like web certificates, "always allow" "this time only" etc. so a more secure setup would allow PhotoEdit full access to c:\documents but only after the user first tried to use it and clicked "always allow".

Allowing any executable access to the whole file system upon a simple request is an outdated methodology. OS's should instead move away from hacked together "system folder" traps and towards a more "top down" approach. This is also simpler than a firewall type approach to FS tech as the OS root is fundamentally protected "out of the box" by being on a different branch of the FS tree. And a mounted virtual directory approach could also be included, the net could be easily firewalled by having the tcp/ip stack a root mount (c:\tcpip) with programs reading and writing to it as they would a file (c:\tcpip\http\\

It doesnt take too much imagination to then extend this approach into ram, where programs reside and what address space they can influence should directly mirror their position in the FS. Therefore also removing the ability for malicious programs to subvert the FS protection by jumpimg address space into a region with full FS write/execute permission
This discussion has been archived. No new comments can be posted.

Suggested new OS FS permissions/security model

Comments Filter:
  • This model is widely used in Unix and Unix-like OSes. Check out the chroot call (and command), and jail() in some BSDs, which is generally thought of as a super-chroot. Essentially chroot changes the "top" of the filesystem for the process and any of its child processes to the directory you name. Once in there, the process simply cannot access anything higher up. You can use hardlinks (multiple directory entries for the same file) to provide access to shared files.

    In the OpenBSD system I use as my firewal

It is masked but always present. I don't know who built to it. It came before the first kernel.