On Mon, 21 Mar 2005 19:57:00 -0800, Matt Zimmerman <[EMAIL PROTECTED]> said:
> I've already stated my position on the bug, and I think that this > use of the staff group should be avoided. > The fact, though, is that this is a privilege escalation from the > (documented, but essentially unused) 'staff' group to root. This is true. But while there is no hard separation, the privileges granted to group staff are not coincident to the privileges granted to the super user; though there is an overlap that can lead to escalation. While you can't use group staff to create a second teir group of humans with some, but not all, rights of the group who has root privileges, you can use to allow people who already have the root password to perform some tasks while they are not root. While in a role as group staff, some of the consequences of actions taken in error (rm -rf $workdir, when -z $workdir, for example) do not have the consequences that they would ahve were they forced to work as the super suer. This overlapping, but not coincident, set of privileges are what makes the group staff useful. There are all kinds of tools in the admins arsenal, each with varying degrees of risk; forcing the admin to run as root all the time reduces, rather than enhances, system security. > Similar escalations exist commonly in other systems via, e.g., the > 'bin' user/group which owns binaries in the default PATH. The > "kmem" group also leads trivially to root. But unless the system > administrator takes it upon themselves to give these privileges > away, there is no realistic attack vector, and no justification for > alarm. Even more directly, sudo and super can be set up to allow trivial privilege escalations (I mean, that is their _job_). There are all kinds of tools and mechanisms that can be set up badly; but that does not mean that we should ban them out of hand. manoj -- Marxist Law of Distribution of Wealth: Shortages will be divided equally among the peasants. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]