[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: How Unix manages processes in userland
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
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 consent
3) preserve a trusted communication path with various levels of control
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
So 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
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
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
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
Things like systrace and SE linux try to apply privilege restriction at
a level where there are complex interactions between things treated as
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
Main Index |
Thread Index |