Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: Terry Lambert <email@hidden>
- Date: Thu, 30 Oct 2008 12:41:37 -0700
On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote:
What's needed is a very fine grained set of capabilities, along with
the ability to selectively grant those capabilities to an
application at either installation or execution time (with
corresponding limitations on the ability to influence the execution
environment ala the existing restrictions for setuid binaries).
For capabilities based security models, all the capabilities that will
ever be available to the OS are created when the OS is started. The
problem with this approach is that it ignores the ability to enter and
leave security associations, or otherwise find some way to escalate
privilege beyond what you start with; on top of that, you have the
problem of initialization. For a capabilities based OS like EROS,
this last one is side stepped by creating the OS image instance with
the instances preinitialized. But even so, the model is a non-
starter. Any time you join or leave a security association, you must
by definition engage in privilege escalation and deescalation, or talk
to a gatekeeper with the capability you want to inherit, and which is
therefore an attack surface. Even if you solved that, you still have
the problem of peer recognition, and, up the chain of trust, that the
person telling you to recognize a peer is a person authorized to do
so, etc..
-
As far as installation time grants, historically computer scientists
have called those "installed images". VMS had this ability, for
example. I'm not, in principle, against those, as long as there is
some other user controllable way to get the same rights for my
software that are being granted by my OS and OS vendor to some other
software vendor installing code on my machine. If I paid for the
atoms, I own them, and they will freaking well do what I tell them to
do.
Ironically, your straw man of privileged ports that you are putting
forward in this thread in order to argue this point was an attempt at
increasing the granularity of the UNIX security model. The idea was
that you escalated privilege as a result of install time rights
settings, obtained your privileged port, then dropped privilege. The
premise behind this is that machines were so expensive that only
trusted parties could afford to buy them, and therefore it was OK to
let root on one machine vouchsafe an identity to root on another
machine.
I would argue that at this point, I could impersonate any machine at
the wire traffic level using cheap hardware, and illicit network
connectivity is so easy to obtain, that the use of privileged ports is
largely useless, outside the computer equivalent of gated communities.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden