Messages in this thread | | | Date | Fri, 11 Feb 2000 09:54:11 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: 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/
| |