Damian Gerow([email protected])@Thu, May 27, 2010 at 11:41:20AM -0400:
> (Perhaps a bit of a newbie question, but I'm not finding anything on
> Google.)
>
> I'm working with some people to restrict our current sudo configuration from
> ALL to something a little more reasonable. Until we fully adopt a
> whitelist configuration, we've got a blacklist in place with the usual
> suspects: editors, shells, sed/awk/tee/perl, etc., as well as some more
> obtuse ones (specific to our environment).
>
> So we started playing around with the configuration, seeing how many holes
> we could find (stress relief), and we were surprised to find the following:
>
> % sudoedit /etc/sudoers
> Sorry, user dwg is not allowed to execute 'sudoedit /etc/sudoers' on <host>.
> % ln -s /etc/sudoers bob
> % sudoedit bob
> <make changes, save, quit>
> %
>
> The shocking part isn't the 'sudoedit bob', but that my user is allowed to
> create the symlink in the first place. sudoers is 0440, and I'm not in its
> group, so I'd have expected this to fail.
>
> I could have sworn that I'd be unable to symlink to a file to which I have
> no read access, and my co-workers felt the same way. In fact, I have very
> specific memories of being unable to do just this, but I've been able to do
> it on multiple systems (various Linux flavours, up to FC11, and a very
> recent FreeBSD). So, it's possible that I'm just confusing things with an
> OWL/GRSec/etc. kernel from a previous life.
>
> So, leaving aside the fact that a 'proper' sudo configuration based on
> blacklists is impossible, my questions are:
>
> Is this behaviour not tunable? Is there some knob somewhere I can twiddle
> to not allow symlink creation to files to which the user has no read access?
>
> But perhaps more importantly, I don't understand why I'd be allowed to do
> this in the first place. Why should a generic user be allowed to create
> symlinks to protected system files?
This is somewhat implied in the man page for sudoers:
SECURITY NOTES
It is generally not effective to "subtract" commands from ALL using the
'!' operator. A
user can trivially circumvent this by copying the desired command to a
different name and
then executing that. For example:
bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or
SHELLS since he can
simply copy those commands to a different name, or use a shell escape
from an editor or
other program. Therefore, these kind of restrictions should be
considered advisory at
best (and reinforced by policy).
Symlinks use the permissions of what they point at. Think of them as free
text: "I point to foo". As an example, try "ln -s
/tmp/nowhere/${RANDOM}${RANDOM} foo" . See how it works, even though that
source doesn't exist?
houd...@linode:~/ > ln -s "/tmp/foo/${RANDOM}${RANDOM}" fo
houd...@linode:~/ > ls -Fal fo
lrwxrwxrwx 1 houdini users 19 May 27 11:58 fo -> /tmp/foo/2034219397
houd...@linode:~/ > ls -Fal /tmp/foo/2034219397
ls: cannot access /tmp/foo/2034219397: No such file or directory
(Ignore my typoed "foo")
--
Bill Weiss
How To Write Good
19. One-word sentences? Eliminate. Always!
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.
