On 2013-12-07 jklowden%schemamania.org@localhost wrote:
Matthew Orgass <darkstar%city-net.com@localhost> wrote:the basic Unix/BSD security model, while useful for servers, does not cover how users actually interact with a personal computer.For that to be true, you'd have to explain how a personal computer is not like a server, and why that matters to the security model. ISTM the Unix security model was invented precisely to control user interaction with the system.
Servers usually are trying to accomplish a more limited task, so it is often possible to run fewer and simpler applications and to put some effort into determining what should be run and as what uid/gid and then setting it up so that happens. I think the basic issues affect servers as well, just much less severely. Personal computer users run and install software without trusting the source, but the current security model is based on trusting applications. Often it is quite complex software and we want to be able to try it and see how it works before putting any significant effort into setup.
In terms of a security properties, I think what I am most looking for is to control:
1) what gets written to disk, particularly so that stuff I care about doesn't get overwritten but also to be able to tell what is using disk space and be able to delete stuff that isn't needed when the disk fills up (and ideally prevent it from unnecessarily filling up in the first place)
2) private data should not be removed from my computer without my consent3) preserve a trusted communication path with various levels of control software
4) get good battery life on mobile devices and still be able to play audio and video without skipping
With #3, #1 could be implemented as a reliable rollback mechanism. #2 is harder, but very important IMO. Solving #2 is likely to make other options available for #1. Also, in general an application like mplayer usually has no need to write to any file at all but contains a lot of complex code from a variety of sources, so being able to easily and reliably prevent it from doing that ever would eliminate a whole class of possible issues (there are still side channel issues, of course, and potential issues with whatever i/o methods it uses).
Networking was never really integrated into the Unix security model that much, and being able to revoke any network access for a process and its decendents seems like a basic minimal starting point to even possibly be able to address #2.
#4 has often not been classified as a security issue, but unintended sucking of battery life is a DOS attack that can be very significant in practice and the control methods needed to deal with it are closely related to other security properties.
Fixing that involves defining and limiting what any individual application and application instances can do (in a way relevent to the user, such as this app can only modify files in this particular directorySo you want to associate permissions with programs instead of users. Which is what setuid(2) gives you without creating a new vector of things that can have permissions granted to them. That it's not used very much suggests to me the "application may do" model is of limited use.
setuid doesn't really do most what I am looking for and is clunky at what it does do. True capability systems are one extreme form of application based privileges and I think there are some ways that those ideas can be useful within an overall more unixy framework.
It seems to me that one core aspect of the traditional unix model is "the privileges of a process or any of its direct decendents will never increase" and IMO that seems likely to make a better foundation than a true capability system if most code runs with almost no privileges and simpler privileged code organizes higher level tasks (this is much more easily said than made to work in practice :/). OTOH, there are already multiple ways that things don't quite work that way in practice and it seems to me like some such way is needed. IMO, descriptor passing should be the main such method and there should probably be some increased ability to pass capabilities via file descriptors (being careful how this affects current apps). OTOH, passing a descriptor should give the application the ability to use the descriptor, not have some magical effect.
Describing file privileges in terms of read/write/execute for user/group/other also seems fundamental to me; it might be possible to tweak that a little (I've wondered if subuser users and groups might make sense or some other method of one login user using multiple uids), but any major change probably means it is a bad idea to try to run in the same OS as apps designed for the current model. I think it would be possible to associate decreased permissions with an application by some other method, but not increased.
Since networking is currently so permisive there is a lot that could be done there that would cause current apps to fail in a safe way when run in the restrictive environment. I also think there could be a unified privilege delegation model that could assign particular privileges to particular uids without breaking the fundamental security model (NetBSD already has some ways of doing that), although there are also many failed attempts to do this and I don't like any of the more general ones I've seen (most of what is called capabilities on unixy systems are trying to do this).
Whatever basic model is used, the main challenge seems to me to be able to define privileges in a way that is useful but not annoying to the user and can be enforced reliably. When try 1 at doing this fails it should also be possible to make a reasonably safe transition to try 2. It should be possible to have split points in simpler privileged code that can choose one method or another such that most code will not have access to both methods, although this can easily get complicated. Some possible uses of a dbus type system would need to do this to be safely used with current code.
Things like systrace and SE linux try to apply privilege restriction at a level where there are complex interactions between things treated as separate privileges.
I don't think Plan9 directly tried address the issues I mentioned but has some ideas that might be helpful.
Phone oriented OSes seem to be trying various new security models, although I don't know much about the details.
It might make sense to create a basic "server of hardware" via the current code base and run a completely different OS with a completely different security model in a virtual machine. OSes with significantly different security models that I know about have so far tried to run directly on hardware, which makes it very difficult to support enough hardware to reach enough potential users to possibly have an impact.
OTOH, I tend to think it is possible to adapt the current model in a way that provides a smooth transition with a configurable level of security vs. interoperability with current applications that fails in a safe way. Some things that make sense to me to start in that direction are:
1) a disable_network() system call and no_new_file_desciptors() system call (and equivalent flags to posix_spawn). Possibly some other way to pass descriptors that doesn't use AF_UNIX.
2) a highly restricted execution environment such that a process basically can just use the file descriptors passed to it. Also, a way to associate this with a particular application such that it cannot be accidently run outside that restricted environment. This might need changes to how shared libraries are loaded to work.
3) a service framework that can help organize #2 and new shell functionality to help organize #2
-Matt