Pavel Machek <pavel@suse.cz>:
>Sorry, disabling exec is security by obscurity (it will deter 95%
>attacks, still!). You can do exec without actually invoking exec
>system call -- you close some fds, mmap executable somewhere into your
>address space, unmap old files ... and you've done exec() without
>actually doing exec. (Mj's freezer does something pretty similar --
>for example he could freeze bash then unfreeze it into your web
>server!)
Not completely - a MLS environment usually includes capabilities. Yes, the
emulation of an exec is possible, but only for the already present
capabilities. In the form described, it is more like an overlay. Use of
shared libraries is also possible (same type of implementation too), but
it is not possible to gain additional capabilities by a subsequent attack
on privileged utilities. This requires an exec system call to evaluate
the security permissions before granting access. Think of an attempt to
change a password. Unless the password program is exec'ed, the privileges
needed to access the password file will not be gained. In the case of
a web server, if exec is not permitted and is not allowed to change security
configuration itself, then attacks against privileged utilities are blocked.
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)
On one system I use (Cray UNICOS), the shell cannot change security
classifications without:
1. be a login shell with a parent process that is flagged as a security
user entry point(telentd/sshd recieve these privilages).
2. have no subprocesses
3. have no open output files other than the controlling terminal (ie. don't
redirect stderr to a disk file...)
4. have the permission to change (elevate) security access.
5. can not raise level above that of the user connection (ie. secure
wire, labeled network connection).
At least two of these get broken with a web server:
1. a web server should not be labeled as a user entry point
4. the web server sould not be labeled as such.
There are other restrictions that can be applied by modifying the web
server itself:
1. deny fork capability in children of the listening web server.
2. deny any open for write capability.
3. deny listen, bind, connect... capability in children of the parent web
server (no new network connections will be allowed after fork).
Hey - thanks for pointing it out for more clarification. Hope this helps.
-------------------------------------------------------------------------
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:30 EST