Suggestion and offer for new restricted priviledged process system

Nicolas Williams Nicolas.Williams at ubsw.com
Thu Jun 22 15:55:15 EDT 2000


A few colleagues of mine and I came up with an idea for a restricted
shell environment based on interposing system calls via pre-loaded
shared libraries.

I've done some preliminary tests that indicate that this approach would
work and have written about 1,000 lines of C consisting of most of the
necessary system call wrappers. We do not have the resources at this
time to continue this process, but since we do make use of SUDO, and
since we want to be able to use such a restricted shell system we would
consider contributing this source code to an open-source project such as
SUDO.

The system calls wrapped include:

 - open()		# To allow control of file access and for logging
 - creat()		# To allow control of file access
 - close()		# To keep state
 - access()
 - fcntl()/dup()/dup2()	# To keep state and for logging at exec*() time
 - exec*()		# To control program execution and for logging
 - set[gu]id()		# To control privileged operation
 - sete[gu]id()		# To control privileged operation
 - setre[gu]id()	# To control privileged operation
 - get[gu]id()
 - gete[gu]id()
 - kill()

The exec*() wrapper would propagate the pre-loading of the restricted
process system to any shell, editor and similar program exec()ed by the
current process, but not to simple programs (this would be
configurable). Or the library could always be pre-loaded, though acting
differently depending on the process hosting it (e.g., shells versus
filters). Thus protecting against sub-shell abuses.

Shell/editor processes restricted in this way would run with ruid or
suid == 0 and euid == real user's and would change those values as
necessary.

The system would never execute any untrusted programs with the library
pre-loaded as it's trivial to write a program that would circumvent it.

Also, all authorization checks are to be modularized so that remote and
local authorization modules can be used. With a remote authorization
server one could easily implement the authorization logic in a high-
level language, such as Perl5 or Python.

Authorization checks could be performed on file access, process
exec()ution (including arguments, obviously), process kill()ing and
probably others (socket() opening, say).

This approach won't work on platforms which do not support runtime
dynamic linkers and library pre-loading.

Is anyone on these lists interested?

Nico
--




More information about the sudo-workers mailing list