Comment 60 for bug 13795

Message-Id: <email address hidden>
Date: Mon, 21 Mar 2005 06:55:58 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

Manoj Srivastava <email address hidden> wrote:

>> Sorry, but that is not the issue. The attacked machine would not be
>> an exporter, but a mounter of user files.
>
> Umm. The exporter is the one that got attacked, since it has
> the data. every other user that mounts the file system is collateral
> damage.

As far as the exporter is concerned, the creation of a setgid-staff object
may be perfectly legitimate: it may have group staff == GID 50 as a
"normal" user group; it may not have any "local" users or user access; it
may have the exported tree contained within a filesystem mounted nosuid.
(The exporter may be a NetworkAttachedStorage device without any
understanding of users or groups, and without an attackable operating
system.) The exporter is protected against root attacks by its use of
root_squash. It is the "collateral damage" on the mounters, through the
root-equivalence of group staff, that is a root attack.

It is the responsibility of (the manager of) the mounter machine to protect
its (own) security, regardless of any attacks on other mounters on on the
exporter.

>> Suppose I have a bunch of machines, that "share" user files: all
>> NFS-mount /users (containing user home directories
>> /users/*). Getting root on any one of this bunch of machines would
>> allow me to create a setgid-staff file; or maybe I could mess around
>> with the .bashrc of a user in group staff.
>
> I think you did not bother to read my response, since I
> explicitly stated that there is no reason to have /home writable by
> user staff.

I used the name /users, not /home; whether either is group-staff-writable
is irrelevant.

In my example, I properly and legitimately own /users/psz. If I can "get"
group staff on one machine (e.g. because I "got root" there) then I can
create a setgid-staff file /users/psz/attack and "get root" on any other
Debian mounters.

(In my humble opinion having /home group-staff-writable is ugly and
useless, Bill's /home/debs example notwithstanding; but I agree that it is
not a security risk. I only ever mentioned /home because it features in the
justification for the existence of group staff. As far as I see, /home is
not mentioned in the policy.)

>> Arguments about exports with squash_gids are moot: many NFS
>> exporters do not have that option; and non-Debian exporters would
>> not know or care about group staff.
>
> Umm, non-debian exporters are not covered by policy, and thus
> we do not care about them. And since this is not a client side thing
> at all, this line of argument is just noise.

We only care about Debian machines, and want to protect those that mount
user-writable files.

> I do not see this email in any way pointing to a valid flaw in
> my summary.

OK, let us analyze it in detail. You wrote:

>>> Synopsis:
>>>
>>> Make squash_gids be a default for the NFS server, make /home
>>> not be writable by group staff, leave /usr/local alone.

Though nfs-user-server may "know" about the squash_gids option,
nfs-kernel-server does not.

Group-staff-writability of /home is irrelevant in the security sense.

Your suggestions do not protect against the attack.

>>> ======================================================================
>>>
>>> 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.

Finer control of privileges is useful when they are not root-equivalent.
Group staff becomes a security issue once there are users in that group
(and is useless otherwise). Users in group staff are root-equivalent,
defeating the purpose of finer control.

The crux of the matter is that group staff cannot be used. If it cannot be
used then it should be ditched, regardless of whether it is a security risk
while there are no users in that group.

>>> 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.

Read-only exports do not mitigate the attack (the attacker could get group
staff on the exporter).

Requiring squash_gids on the exporter would ban the mounting from
non-Debian exporters.

Any requirements on the exporter would allow the security of the local
(mounter) machine be controlled by the remote (exporter) machine.

(A partial solution would be to mount nosuid. Another part would require a
squash-gid-on-mount option: mount has no such options for NFS, though has
similar options for some other filesystems; there are also uid/gid mapping
options for NFS exports.)

Anyway, the attack involving NFS was just a demonstration that having
/usr/local group-staff-writable is a security risk even when there are no
users in group staff.

>>> 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.

Export of /usr/local (or of any other filesystems) is not the issue.

>>> 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.

Would you please specify what is the common case? Could you please explain
how it is protected?

>>> Making /home not writable by group staff is more reasonable,
>>> and this should be done.

The current permissions/ownership of /home do not pose a security risk.

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia