on Thu, Jan 03, 2002 at 08:45:43PM -0500, P Prince (princep@charter.net) wrote:
> Well, what about su?
>
> tech@maximus$ su
> tech@maximus's password:
> root@maxiums# shutdown -h now
>
> > I had two ideas of making this possible. The one is to make it sudo-able and
> > the other is to put the executable into a special group (e.g. poweroffer)
>
> Sudo is a security hole.
In the context of what you've just stated, it's less a security hole
than the alternative you've provided. If your alternative to sudo is
su, you've just addressed the problem of providing a user unintentional
full root access...by providing her intentional full root access.
Because of the inherent granularity of the GNU/Linux security model,
implementing controlled security on a GNU/Linux system takes some
thinking.
For those wanting more background on this topic, Ethan Benson and I
discussed the topic on list some time back.
> There are three ways to use it, one good, one questionable, and one
> stupid.
Note that the sudoers manpage itself makes the same observation.
> The good way is to set your user account to have full root privs via
> sudo. This is very handy to have, because you can do root things
> without having to su.
You also log *all* sudo events, the command issued, and its arguments.
> The questionable way is to allow certain users to execute a certain
> set of programs as root.
If the alternative is direct root access (which is denied or otherwise
prohibited), this accomplishes two things:
- All root accesses are tied to a user account. With appropriate
(this means off-system) logging, you can at least retroactively
restrict that user's access to systems. The problem of "mystery
root events" (I've seen same, in an environment where workstation
root passwords were shared...not mine however) is at least reduced
to "root event from account X".
- A shared root password isn't needed. Users with sudo root access
need to practice good password discipline, but the cleanup required
after (or before) a problem / transfer / termination is greatly
reduced.
- The solution is scalable. A users permissions can be increased or
decreased within sudo. su doesn't offer this same level of control.
> It works well, but if you are not extremely careful about write
> permissions on the executables and all of their parent directories,
> you can make it possible to overwrite an allowed program with one of
> your own. Even more likely, you can force trusted programs to execute
> non-trusted programs with the same effective UID.
There are more problems with this, and they're the same ones you'd have
with a shared root account, excepting the comments I've made above.
> The stupid way to use it is to allow a user full root privs, with some
> restrictions.
Agreed. From man (5) 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.
Other things to watch for are *any* command that allows shell access.
This restricts the utility of sudo with, say, editors and other
interactive tools. But it should generally be rarely required with
same.
Note that if a user is allowed to create or move arbitrary files with
root privileges, they can replace files to provide themselves a root
shell.
Security is a process, not a state.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/ Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
Attachment:
pgpi32bruXGoK.pgp
Description: PGP signature