On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
>In this report, the submitter complains about /usr/local/bin being in
>the PATH by default at the same time directories under /usr/local are
>root:staff and world-writable. His complain is based on the existence
>of become-any-group-but-root bugs.
Not world-writable. Writable by group staff.
>If this is a bug at all, I think we should probably drop the root:staff
>thing instead of changing the default PATH. So: Would anyone here
>second the following patch, if it were a policy proposal?
Having /usr/local staff writable is *very* useful when using CPAN to
install local packages w/- having to do the "make install" as root.
This is a benefit I'd prefer not to see removed, since the alternative
generally involves giving sudo access to a subset of users... which is
in my experience tantamount to simply adding more entry points to
gaining uid=0*, worse IMHO than having a subset of the filesystem
writable to that same set of users.
I would see setting root's PATH set to /bin:/sbin:/usr/bin:/usr/sbin as
a much better option than removing staff writability of /usr/local.
Although it's probably worth considering that there's more at stake here
than just PATH, since perl for example has /usr/local/{lib,share}/perl
earlier in @INC than /usr/{lib,share}/perl... Giving an attacker who
has breached a group staff acount another avenue: creating say
/usr/local/share/perl/5.8.4/strict.pm containing malevolent code if
$> == 0 would likely be tripped sooner or later.
I'm not sure what the emacs site-lisp search order is, but that may well
provide a similar vector.
In summary:
1. The Debian installer does not (AFAIK) add any user to group "staff"
by default, so this is not an issue for every installed Debian
system.
2. We need to assume some competence on behalf of the administrator as
to who gets added to group "staff", just as we would with respect to
addition to /etc/sudoers or who was given the root password.
3. To mitigate the effects of compromises of group "staff" users, the
default root PATH should not include /usr/local; the administrator
may choose to type the full path if required (just as they must for
the case of ".").
4. Perl (and other packages which preferentially load executable code
from /usr/local) may need to be modified to invert the module search
path order for uid=0.
--bod
* sudo is fine for specific tasks, like "sudo mount /media/cdrom", but
woeful for things like "sudo make install". Worse, I've seen "sudo
bash" more times than I care to recount.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
