By default, in Debian, /usr/local is integrated into the OS,
it is in the default path for root, it is in the library path for
systems like Emacs, Perl, Python,, etc.
/usr/local, by default, is created group writable by group
staff. This is not a security issue on the local machine, since by
default group staff is empty, and there are no sgif staff binaries in
Debian It is present to allow a finer distinction of privileges on
the machine, by adding people to group staff one may allow people to
update bits of /usr/local (like, for instance, installing CPAN
modules, elisp packages, CTAN bundles, etc). Having finer grained
privileges is a nice feature; anything to prevent the blunt use of
super-user in Linux is something we should encourage. There fore it
is better to do this by default than making every local admin do it
on their own.
The problem comes with NFS. If the system is not exported
read-only in NFS, then any exploit on the remote machine may
compromise the local machine. There are mechanisms in place to
prevent this from happening:
a) export the file system read only.
b) export the file system with root_squash on squash_gids
c) use SELinux on both ends and label the network and use the
patched SELinux aware NFS code :P
The issue is that by default only root_squash is enabled, but
not squash_gids, which seems to be the crux of the problem
reported. Fixing that is a better solution than forcing the local
administrator to add more entry points to gaining uid=0* (using sudo,
for instance), instead of giving these local roles the ability to
write to a subset of the file system.
Also, the vast majority of installs do not NFS export
/usr/local, so while they can benefit from the finer grained control
of who can write to /usr/local, they won't benefit from the "don't
need to add squash_gids". Even in the subset of machines that NFS
export file systems, not all of them export /usr/local; so we are
talking about far different constituencies here.
The common case by far benefits from /usr/local not requiring
uid=0 to modify; and we should be making things easier for the common
case, and not too much harder for the uncommon.
Making /home not writable by group staff is more reasonable,
and this should be done.
manoj
--
Feminists just want the human race to be a tie.
Manoj Srivastava <email address hidden> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 10:45:20 -0600
From: Manoj Srivastava <<email address hidden> (va, manoj)>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Synopsis:
Make squash_gids be a default for the NFS server, make /home
not be writable by group staff, leave /usr/local alone.
======= ======= ======= ======= ======= ======= ======= ======= ======= =======
By default, in Debian, /usr/local is integrated into the OS,
it is in the default path for root, it is in the library path for
systems like Emacs, Perl, Python,, etc.
/usr/local, by default, is created group writable by group
staff. This is not a security issue on the local machine, since by
default group staff is empty, and there are no sgif staff binaries in
Debian It is present to allow a finer distinction of privileges on
the machine, by adding people to group staff one may allow people to
update bits of /usr/local (like, for instance, installing CPAN
modules, elisp packages, CTAN bundles, etc). Having finer grained
privileges is a nice feature; anything to prevent the blunt use of
super-user in Linux is something we should encourage. There fore it
is better to do this by default than making every local admin do it
on their own.
The problem comes with NFS. If the system is not exported
read-only in NFS, then any exploit on the remote machine may
compromise the local machine. There are mechanisms in place to
prevent this from happening:
a) export the file system read only.
b) export the file system with root_squash on squash_gids
c) use SELinux on both ends and label the network and use the
patched SELinux aware NFS code :P
The issue is that by default only root_squash is enabled, but
not squash_gids, which seems to be the crux of the problem
reported. Fixing that is a better solution than forcing the local
administrator to add more entry points to gaining uid=0* (using sudo,
for instance), instead of giving these local roles the ability to
write to a subset of the file system.
Also, the vast majority of installs do not NFS export
/usr/local, so while they can benefit from the finer grained control
of who can write to /usr/local, they won't benefit from the "don't
need to add squash_gids". Even in the subset of machines that NFS
export file systems, not all of them export /usr/local; so we are
talking about far different constituencies here.
The common case by far benefits from /usr/local not requiring
uid=0 to modify; and we should be making things easier for the common
case, and not too much harder for the uncommon.
Making /home not writable by group staff is more reasonable,
and this should be done.
manoj www.debian. org/%7Esrivasta />
--
Feminists just want the human race to be a tie.
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C