On 31 May 2010 21:44, Steve Holdoway <[email protected]> wrote:
> Even though you lose the accountability of the sudo log, it still does
> add extra protection of not being to remotely log in as root, and
> there's no password, no certificate to enable it if/when you get there.

If all you're looking to do is prevent root login, sshd_config can do
that.  Having a "locked" or password scrambled also adds some
protection on a local level.

> Yes, I know there are other ways of doing it. All have their pros and
> cons... and I suppose sudo hasn't been tested by the hackers yet. After
> all, DNS was secure as until that happened (:

Sudo has flaws and has been attacked by hackers.  One of the easiest
is exploiting bad/lazy admins who don't set full paths of restricted
commands.

Example:
jdoe ALL = mount
jdoe ALL = shutdown
jdoe ALL = /usr/bin/rsync

One might think that this limits jdoe to run mount, shutdown, and
rsync.  But there is nothing from stopping them from creating a script
or copying bash to a local "mount" and then running that.  So you
should include full paths, and if possible, arguments.

jdoe ALL= /bin/mount /mnt/foo

Even though the rsync has a full path, rsync can be used to copy
files, so it can be used to copy/delete files as root.

There are also some local process escalation tricks involving SMP and
threads that allow you to keep root permissions.  I think sudo is a
great tool, but it's just one of many in my toolbox.

sV

Reply via email to