Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: Terry Lambert <email@hidden>
- Date: Fri, 31 Oct 2008 12:21:00 -0700
On Oct 30, 2008, at 4:09 PM, Brian Mastenbrook wrote:
On Oct 30, 2008, at 2:41 PM, Terry Lambert wrote:
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..
I am somewhat confused by what you are saying, as my prior exposure
to the capabilities model is within the context of the actors model
(for example, as implemented in E) where it definitely is possible
to create a capability after the system is started. This is probably
a bit of a tangent for darwin-dev; I'd be happy to discuss further
over private mail.
I really don't understand how you could possibly use that approach to
add a new capability which, for example, allows an otherwise normal
process to create privileged ports, if that granularity wasn't there
in the first place. You'd of necessity need to have rights to define
the capability, and you'd have to have rights to assign that
capability, and you'd have to have an apriori knowledge of that as a
discrete security boundary crossing event within the kernel itself,
and an interposition enforcement checkpoint.
All I see happening from this is moving the target surface, not
eliminating it. If I can't attach a process "bob" which was setuid to
enable it to get a privileged port, because what I want is a different
privilege than that one, then I'll just attack the process by which
privileges are created or the process by which privileges are assigned
to process "bob", etc.. It's like yelling "Look! A pony!". The weak
link is always going to be (1) the human who is asked to add
privileges, or (2) the system's recognition that a given human is in
fact the right human to permit to add privileges.
I actually expect things would be worse than that; the only model that
really works for interposition checkpoints is to allow multiple
control agencies, and if anyone says anything other than "Yes" or "I
don't care", then the answer is "No". Since the default answer is
"No" for privileged ports, there's no way you could change the answer
to "Yes" without allowing the policy to change the default.
Otherwise I can just get a "Yes man" policy loaded at some point, and
all your guards look the other way.
The reason I brought up privileged ports is that this is one of the
examples given in BetterAuthorizationSample, and despite the
complicated attempt to provide only the ability to open up certain
ports to the requesting process, the ability to do anything which
requires admin privileges is provided to any process which is
running as the requesting process's user.
Sorry, I don't know from BetterAuthorizationSample. I just manage the
credential code by which user space establishes identities to the
kernel. I deal with 32 bit integers or interfaces to ask a privileged
process in user space to trade things I don't know from Adam for nice
32 bit integers. 8-).
Internally to the kernel, we *have* an actor model: all our kauth
questions are of the form "Is actor X allowed to perform operation Y
on taget Z?".
If you want, I suggest you file a bug against
BetterAuthorizationSample to get them to pick a different example.
-- 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