lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Capabilities
Chris Evans <chris@ferret.lmh.ox.ac.uk>
>On Thu, 10 Feb 2000 willy@thepuffingroup.com wrote:
>
>> it though. One thing the capabilities people could help us with is by
>> saying whether they are willing to restrict themselves to 32 capabilities
>> for ever or whether they think they will need more (and if so, how many?
>> Is there a realistic upper bound?).
>
>In 2.3 I believe we are currently using 28/32.
>
>We are just starting to see some real-world usage of capabilities, in the
>form of restricting the capabilities certain daemons are running with. As
>capabilities are used more, a few ommissions will be detected and I think
>we will overrun 32 bits.
>
>Since filesystem data structures are, shall we say, tricky to change after
>the fact, PLEASE budget 64 bits. 64 bits should suffice relatively long
>term. Do people concur?

Definetly want more than 32. I'd like to (potentialy) be able to control
every system call through a capablity. I'm also a strong fan of MLS
systems, it lets my paranoid side out when protecting systems:).

I'd suggest using an index reference to a table containing multiple capability
lists. The set of usable capability lists is limited. Many inodes, but the
number of uniqe capability lists would be rather low (20-30 most likely).
Using a reference:

1. reduces the impact on an inode (8 bits would allow for 255 different
capabilitiy lists - reference 0 represents no list)
2. centralizes control over what capability lists are allowed; multiple
inodes would be able to reference the same capability list.
3. allows customization by the security administrator (users would not
be able to create arbitrary lists)
4. Allows more capabilities to be added without impact to the inode
structure, only the reference table support.

Some additional administrative information could be determined easily too -
if a "link count" is updated each time an inode is given/removed a capability
reference, then the total number of files making use of the capability list
would be known; as well as any unused definitions.

I'm in the process of setting up a secured server system (using RSBAC) and
I would like to run the web server in a compartment, without the ability
use the exec system call. Yes this restricts a lot of CGI capability, but
does allow the use of Java (as part of the server) and mod_perl. The web pages
(and data files) will be stored at a security level below that of the server
process.

This configuration would prevent any hack entry into the server (via bugs/
stack overflow, etc) from being able to do anything to the data (no write
down). Without the exec, no shell process could be generated. The most that
could be done is aborting the server process. Since these are usually children
of a parent server, they would normally be restarted when needed (parent would
have fork, and listen).

Extended capabilities would allow me to detect/prevent hacking output data
by changing the server. Admittedly, it would not prevent replacing the
functionality of a web server (say by loading a bogus Java/perl server and
running it) but if the remaining capabilities prevented the use of the "listen"
system call (only the parent server listens) then even this attack would be
defeated. (The Apache server would have to be patched to drop the capability
to use the listen system call after the fork).

BTW, this is an experimental configuration, intended only for my use.
(results may become publishable though...)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

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