lkml.org 
[lkml]   [1998]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support
> On Sun, 19 Apr 1998, Albert D. Cahalan wrote:
> > * a Bounding Set that serves as a fail-safe mechanism to ensure users
> > cannot acquire more privilege beyond what they have been authorized

One of the critical things about the capability model is the movement
away from having executables spontaneously acquire privilege by simply
being invoked.

This is one of the main problems with the historical suid model: a
program gets all the power when it starts up. There are frequently
new attacks on programs that exploit such a feature. Passing command
line arguments that overflow a stack comes to mind...

The capability model is designed to change this. The recommended
behavior for an executable on a fully capability-aware system is to
not raise "effective" capabilities on startup. Since, without them, it
has no immediate power. In order to become powerful, it needs to
request that one or more of its permitted capabilities be made
effective, with a system call.

The recommendation is that before this is done, the application
"authenticates" the requesting user and context of the request. This
authenticaton can be as strong or as weak as the application sees fit
-- from don't care, to please step up to the retinal scanner -- but by
providing some distance between acquiring the potential for power and
actually activating the power there is at least a window of
opportunity to authenticate the request. The fundamental point being
that authentication (firewalling if you like) is the only way to
enforce a security model.

The single bit 'fE' capability 'set' is the smallest hack possible to
provide backwards compatability for legacy setuid applications. For
all the reasons that the capability model is a good one, making use of
'fE' is strongly discouraged. The obvious alternative to a single bit
of 'fE' capability is to have a complete multi-bit 'fE' set --
indicating which of the new process' permitted capabilities should
raised in the effective set. fE is defined to be one bit to strongly
discourage this "lack of programming" practice.

Chris Evans writes:
> I perceieve the main benefit of this for users like "nobody"; with an
> empty bounding set the user really can be "unprivileged", in the sense
> they can't try and exploit your SUID/privileged programs to gain a root
> shell etc.

The point you raise here about "nobody" getting some power, is an over
generalization.. In some rare cases (contexts), it may be appropriate
for the "nobody" user to exercise a capability. In these cases it is
the "authentication" component of the application that needs to make
this decision and because of the context, this is generally not
something that can be reduced to a couple of bits in the file's
attributes.

I hope that helps clear things up..

Best wishes

Andrew

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.119 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site