Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Mar 1999 14:18:05 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        bmah@CA.Sandia.GOV (Bruce A. Mah), freebsd-security@FreeBSD.ORG
Subject:   Re: sudo (was Re: Kerberos vs SSH)
Message-ID:  <199903252218.OAA03395@apollo.backplane.com>
References:  <199903252032.MAA25377@stennis.ca.sandia.gov> <v04011701b32060ab1ee4@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help

:is a very useful tool.  At least, it (or programs like it) are
:better than other alternatives.
:
:It beats making executables setuid, for instance.
:It beats having lots of different people with the password to
:root, and the ability to run *anything* and do *anything* that
:they want.
:
:Just my 2 cents worth...

    This is my view:  If you can't trust someone to know what to 
    do with root access, you don't give it to him.  At all.  Not
    one tidbit.  Not even sudo.  If you can trust someone, you give
    them root access via ksu.  There is no 'grey area' with me. 
    Anything that 'requires' someone to run something as root where
    someone != sysop is a misconfiguration.  For example, you don't
    give the webmaster root, you run the WWW server under a uid
    that the webmaster has access too and if you want to protect
    certain parts of that further, you make certain portions of 
    that tree owned by root ( including the 'home' directory ).

    Another example:  DNS zone files are mostly owned by root and
    placed in a special group, modes 664.  The most critical
    zone files and the automatically generated ones can be owned by
    root modes 644.  The hostmasters do not have root, but they
    are placed in the appropriate group in order to be able to
    do their job re: the zone files.

    There are lots of cute tricks that can be played with group perms.
    For example, mode 1770 directories owned by root.<somespecialgroup>.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903252218.OAA03395>