>>>> ... any machines that share user files via writable NFS mounts are
>>>> vulnerable. (Are vulnerable if you mount an NFS filesystem that is
>>>> writable to others.)
>>>
>>> No that is not true. You need to use root_squash for any semblance of
>>> security anyway. In that case you can also use squash_gids to prevent
>>> the attack.
>>
>> Note that root_squash is default, squash_gids is not; there is no
>
> Then the solution is to make squash_gids staff the default.
>
>> recommendation to squash_gids staff. My machines do not know about
>> squash_gids (in "man exports", package nfs-kernel-server, versions
>> 1.0-2woody3 or 1.0.6-3.1);
>
> At least woody nfs-user-server has it.
>
>> I wonder if non-Debian OSs know.
>
> How is it relevant ? this is a server-side setting.
The root-squash and mooted squash_gids options are for the server exporting
the tree, the attack is against the machines mounting it. The exporter may
be a non-Debian server, or it may be Debian using nfs-kernel-server.
Non-Debian servers would not know about group staff == GID 50.
>> (The issue of "real" users in group staff also remains.)
>
> There is no users in staff by default. Member of the group staff
> normally has root access as well. The goal of group staff is to protect
> against errors, not mischief.
Whatever the goal, it must also protect against mischief, unless it is
clearly and prominently documented that giving group staff access is
equivalent to giving root access.
You said earlier that
The first goal of the unix permissions is to protect against errors
rather than malices.
and used the example of the sysadmin who does rm -r /usr/lib instead of
rm -r /usr/local/lib by mistake. I believe that your statements about
goals are wrong. To protect against mistakes use things like
alias rm='rm -i'
Protections and permissions must be enforceable. Security must not depend
on "normally", "probably" or "unlikely" and similar qualifications.
> Ho, and if you did not blacklist me I would be in a better mood to
> discuss with you, thanks. Please read the bug log for other answers you
> might have missed.
I apologize for blacklisting your ISP. Apparently the bounce message from
maths.usyd.edu.au said:
Message-Id: <email address hidden>
Date: Fri, 18 Mar 2005 06:31:17 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Bill Allombert <email address hidden> wrote:
>>>> ... any machines that share user files via writable NFS mounts are
>>>> vulnerable. (Are vulnerable if you mount an NFS filesystem that is
>>>> writable to others.)
>>>
>>> No that is not true. You need to use root_squash for any semblance of
>>> security anyway. In that case you can also use squash_gids to prevent
>>> the attack.
>>
>> Note that root_squash is default, squash_gids is not; there is no
>
> Then the solution is to make squash_gids staff the default.
>
>> recommendation to squash_gids staff. My machines do not know about
>> squash_gids (in "man exports", package nfs-kernel-server, versions
>> 1.0-2woody3 or 1.0.6-3.1);
>
> At least woody nfs-user-server has it.
>
>> I wonder if non-Debian OSs know.
>
> How is it relevant ? this is a server-side setting.
The root-squash and mooted squash_gids options are for the server exporting
the tree, the attack is against the machines mounting it. The exporter may
be a non-Debian server, or it may be Debian using nfs-kernel-server.
Non-Debian servers would not know about group staff == GID 50.
>> (The issue of "real" users in group staff also remains.)
>
> There is no users in staff by default. Member of the group staff
> normally has root access as well. The goal of group staff is to protect
> against errors, not mischief.
Whatever the goal, it must also protect against mischief, unless it is
clearly and prominently documented that giving group staff access is
equivalent to giving root access.
You said earlier that
The first goal of the unix permissions is to protect against errors
rather than malices.
and used the example of the sysadmin who does rm -r /usr/lib instead of
rm -r /usr/local/lib by mistake. I believe that your statements about
goals are wrong. To protect against mistakes use things like
alias rm='rm -i'
Protections and permissions must be enforceable. Security must not depend
on "normally", "probably" or "unlikely" and similar qualifications.
> Ho, and if you did not blacklist me I would be in a better mood to
> discuss with you, thanks. Please read the bug log for other answers you
> might have missed.
I apologize for blacklisting your ISP. Apparently the bounce message from
maths.usyd.edu.au said:
see http:// www.dnsbl. sorbs.net/ cgi-bin/ db?IP=82. 65.23.158 or mail <email address hidden> if genuine
I will now ask my postmaster to whitelist your email address.
Cheers,
Paul Szabo <email address hidden> http:// www.maths. usyd.edu. au/u/psz/
School of Mathematics and Statistics University of Sydney Australia