[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1070806416.15286.16.camel@miles.debisschop.net>
From: kdebisschop at alert.infoplease.com (Karl DeBisschop)
Subject: Partial Solution to SUID Problems
On Sun, 2003-12-07 at 03:28, Todd Burroughs wrote:
> > Sometimes, old and silly rules aren't just about security.
> >
> > The *real* reason for the "always su from a user account" rule isn't to stop
> > exploits. It's so you have an audit trail of who did what.
>
> This is exactly why I need su. We have about 20 people with root access,
> only about 8 or 10 that regularly change things. You need an audit trail,
> we all make mistakes and it's a lot easier and faster (really important
> on a production system) if you find out who did it and talk to them.
You keep listing audits and account separation, but fail to mention
'sudo'.
With sudo, you can have multiple root-privileged level accounts all with
their own UIDs.
Not only is the invocation of sudo logged, but the cammond issued is
logged, so you may not even need to wake up the unfortunate sysadmin to
find out how to fix it.
Plus, since sudo only elevates the privilege for one command at a time,
you can safely open a browser as a normal user. We all have probably
noticed that when logged on as root, most of your command do not
actually need root privileges -- each of those commends does constitute
an attack vector, however.
Even better, you can restrict the escalation of the privileges so that
some user have full access and others have for example only the right to
restart or reload the web server.
If you are using su to co-manage a server, you may be a little behind
the curve in this respect. I suggest looking at sudo.
--
Karl DeBisschop <kdebisschop@...rt.infoplease.com>
Powered by blists - more mailing lists