Messages in this thread | | | Date | Thu, 6 Jan 2000 18:49:37 +0100 | From | karin@root66 ... | Subject | Re: compartment || the other way of compartment |
| |
On Thu, Jan 06, 2000 at 09:53:38AM -0600, Jesse Pollard wrote: > > You are actually talking about using compartmented mode operation and > mandatory access controls. I do believe that more complete capability > list support will be usefull. Tracking and configuration of capability lists > has been brought up several times without final resolution, since all > implementations seem to need modifications to the filesystem for support. > Some suggestions that came up: > 1. modify the binary header to contain the capabilities of the binary. > problem: anyone that can create a binary would be able to set the > capability list of that binary. How is this prevented. > 2. only inherit capabilities from a parent process. > problem: how are the capabilities initially set? how can a non- > privilege process (say a user shell) run a privileged > application (say passwd)?
You could also just have a config file like /etc/auditopen containing the capability list of the binaries. What is wrong with that?
> Other topics that came up: > > 1. what is a suitable list of capabilities?
You could say that the max list of capabilities is the complete list of sys_calls.
> 2. What granularity is supported by the capabilities?
What do you mean?
> 3. Can site defined capabilities be defined? > 4. (related to 3) Can application specific capabilities be defined?
You could think of extending the configfile from a binary specific to a binary and process specific. But as far as I can see binary specific will to enough. Could you give me an example where binary specific configfiles are not enough?
> > See the RSBAC project at http://www.rsbac.de/rsbac/ > for an implementation of MAC controls, including compartmented operation. > ------------------------------------------------------------------------- > 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/
Frank van Vliet karin@root66.org RooT66 - http://root66.org ShellOracle - http://www.shelloracle.cjb.com
- 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/
| |