lkml.org 
[lkml]   [2002]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Posix capabilities
Date
On Thursday 17 October 2002 12:37, Olaf Dietsche wrote:
> "Theodore Ts'o" <tytso@mit.edu> writes:
> > Personally, I'm not so convinced that capabilities are such a great
> > idea. System administrators have a hard enough time keeping 12 bits
> > of permissions correct on executable files; with capabilities they
> > have to keep track of several hundred bits of capabilties flags, which
>
> So you claim, system administrators are stupid people?

Filesystem capabilities move complexity out of applications into the file
system (=system configuration), so the admins have to deal with an additional
task.

From a security point of view suid root applications that are dropping
capabilities voluntarily aren't much different from plain old suid root apps;
there may still be exploitable bugs before the code that drops capabilities
(which doesn't mean that apps shouldn't drop capabilities). With capabilities
the kernel ensures that applications cannot exceed their capabilities.

I think the remaining questions really are:

- how to populate the database of capabilities needed by apps.
(Pavel Machek has started this as part of elfcap [which is a bad
idea], see http://atrey.karlin.mff.cuni.cz/~pavel/caps/capbase.txt)

- how to make maintaining / monitoring tight capabilities as
effortless as possible.

- how to set up capabilities when users log in (which users are
granted which capabilities; this can be used to split up the role
of root.)

- (maybe some more)

> > must be set precisely correctly, or the programs will either (a) fail
> > to function,
>
> Which you will notice very fast.

Well perhaps not, the admin gets overloaded with requests/complaints, and
finally decides to discard FS caps.

> > or (b) have a gaping huge security hole.
>
> Which is not worse, but possibly a lot better, than setuid root.

It's worse if apps stop dropping capabilities and instead rely on the caller.

--Andreas.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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