Suggestion and offer for new restricted priviledged process system
Nicolas.Williams at ubsw.com
Thu Jun 22 20:31:09 EDT 2000
On Fri, Jun 23, 2000 at 01:17:44AM +0200, Emil Isberg wrote:
> On Thu, 22 Jun 2000, Nicolas Williams wrote:
> A few years back I developed such a library on Solaris 2.5.1...
Cool. Is it available?
> My oppinion is that sudo and such a shell is different approches, though
> they might prove useful together in specific situation. Overall it's not a
> good idea though.
I'm seeking to replace SUDO in this case.
> >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
> Here is the problem: On most unixes I've tried you can't distinguish
> between "simple programs" and "any shell, editor and similar
> program" without specifying each and everyone in a configuration file.
> And you can't specify each and everyone if you allow the users to write
> their own programs or such things.
True, but you can run known shells and editors in the restricted mode,
everything else that's known with no restrictions, but logging all file
open() and exec() events.
> >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.
> Same problem here...
> >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.
> I agree to that, but you can't trust any program (and most specific not
> any shell) on the system.
This is true with SUDO as well.
> >Is anyone on these lists interested?
> Sure. Eventhough I'm sceptical to it's use I'd love to check it...
I want to use this for granted restricted priviledged access to fairly
well trusted users who do application support, but not system
Could they get around this system? But with SUDO we must either not
allow them much useful access and handle the correspondingly high
service request load, or we can give them more access than we'd like
So you see my interest in this. One could get much more sophisticated
with the technical aspects of a restricted process system more general
than SUDO. In fact, there are products on the market that use kernel
modules to implement such things; we need something in between.
More information about the sudo-workers