Messages in this thread | | | Date | Wed, 23 Feb 2000 14:04:06 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
Andrew McNabb <amcnabb@argus-systems.com>: >> On several B2 rated systems, the shell IS capable of requesting level >> changes, and unless the shell is operating in the proper environment >> (capabilities, level, compartment, and process tree) then even the request >> for security change can be a violation. (BTW, the system calls for changing >> security environment has to be built into the shell - they don't work >> otherwise - see below) > >It doesn't have to be built into the shell; you can have a separate >program that asks for the PID of the process to change.
you can try - but it doesn't work (unless you are in the PRIV-SU mode). It's the wrong environment for it to function. I tried it, and couldn't get the right envrionment for it to work. Only the labeled daemons were able to setup the environment, then the shell has to request the change it. It appears (the manpage) that the system call uses the current PID to determine the process tree (setulvl doesn't have a PID parameter).
The reason it doesn't really work is that making such security changes outside the top level environment permits security leaks. Lets take an example: a process exists with the proper level and creates a pipe to a child.
Now the parent process changes security levels to a higher level.
The information leak is provided by processing activity of the higher level (covert channel). A more direct leak is open file id between processes.
The direct leak can be covered by having the change level (setulvl) system call close any open files. It is not possible to fully close the covert channel. The level switch itself causes a one bit transfer - the child can no longer have a ligitimate group head - signals sent to the higher level process (say, terminate) cause the re-parenting of the process tree. The timing of the reparenting event provides the covert link. Lower level processes cannot recieve any information from a higher level process - even a notice of termination.
It is easier to verify that such leaks do not occur by permitting only the process group leader, with no children, to change security levels. Once elevated, they cannot be dropped - the process must terminate, causing a logout.
Note: a system running PRIV-SU enables superuser operation, and all bets on real security disappear. ------------------------------------------------------------------------- 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/
| |