On Thu, 21 Oct 2010 at 17:53:53 -0600, Bob Proulx wrote:
> Giacomo A. Catenazzi wrote:
> > It depends on the definition of "equivalent".

The definition of root-equivalent I'd use is: if an account is compromised (an
attacker gains control of it), and the attacker can get root privileges as a
result, then that account is root-equivalent.

(Privilege-escalation bugs like CVE-2010-2961 make every account
accidentally root-equivalent, which is why it's so important to fix them!)

For instance, group 'sudo' (or 'admin' on Ubuntu) is root-equivalent by
design (although it's a little awkward for an attacker, because they'd have
to insert a trojanned sudo binary into the $PATH and wait for the user to
sudo again in order to get their password). Group 'disk' is more directly
root-equivalent, because you can (for instance) copy /bin/sh to your home
directory and use debugfs to make it setuid-root.

> I expect group staff to have write access to /usr/local so that
> './configure && make && make install' can install software in
> /usr/local but bad software that tries to write to /etc/ will be
> prevented by filesystem permissions.

That's a useful safety net against mistakes, but 'staff' is still
root-equivalent (because it can insert things into root's $PATH). To add
someone to 'staff', you need to trust them not to abuse their ability to
get root (you've said you do trust them that far, so that's fine), and you
*also* need to trust them not to let someone less principled break into their
account (insufficiently good password, stolen laptop, login over telnet,
unintentionally running malicious software, whatever).

    Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101022110402.gb25...@reptile.pseudorandom.co.uk

Reply via email to