Cmnd_Alias subdirectories

[John E Hein]

Simon Perreault wrote at 21:31 -0500 on Jan 11:
 > On January 9, 2002 06:12 pm, John E Hein wrote:
 > > a few things to consider...
 > > You'd have to make sure you followed sym links in the implementation.
 > 
 > I haven't looked at how Cmnd_Alias is dealt with right now, but I'll remember 
 > this.
 > 
 > > How about mount points?
 > 
 > Uh... They're followed? If the recursive options is used, that is.
 > 
 > > etc.
 > 
 > I don't really understand what you're referring to here.

You asked about potential security problems with your proposal.
I mentioned some possibilities.  Let's take the mount
 point issue as an example:

Suppose user X has a Cmnd_Alias that specifies any dir under /a/b/c
Suppose he does 'sudo mkdir /a/b/c/d ; sudo mount somehost:/some/other/dir /a/b/c/d'
Now if you follow mount points for your recursive Cmnd_Alias, then
 he has effectively added commands he can run that aren't really under
 /a/b/c.

Okay, you say, don't allow mount.  What if you NEED to allow him to run
 mount... or what if you allow cp, or creation of sym links, etc... he can
 just use cp or ln (or a dozen other commands) to add ways to run stuff
 you didn't intend for him to run.  Anyway, this is just one example.

You wanted feedback on things to consider if you wanted to implement
 this option.  Maybe you want to have an option to disallow mount point
 traversal.  There's a lot of issues and maybes that will come up if you
 want to allow sudo'd commands under a tree as you suggest.  It made me
 think of a chroot... sorry you didn't see the parallel.

I could see scenarios where you'd like to allow a sudoer limited access
 to a dir tree containing a limited set of commands and not have to
 enter each command individually in sudoers.  I am guessing that's your
 rationale.  Understandable... but if you do this, there will be many ways
 to circumvent it unless you tightly control what commands can be run
 (any command that allows modification or creation of a file under that
 tree is a way to punch through that security, for instance).


 > > What you propose is a kind of chroot.  And it's not hard
 > >  for root to break out of a chroot.
 > 
 > A chroot??? How am I proposing that?

Just an abstraction for purposes of illustration.  Just ignore if the point
 didn't convey.