Dear Steve,
Thanks for your response.
> The bug log indicates that it's only exploitable when
>
> - you have a non-empty "staff" group on the client (+/- equivalent to
> untrusted root users on the client, since any root user can simply add
> users to this group)
> - you have NFS-shared filesystems that aren't marked nosuid
> - the untrusted user on the client has access to run processes on the NFS
> server
> - /usr/local/{bin,sbin} are in root's path
> - /usr/local/{bin,sbin} are writable by group staff
>
> The last two points are true by default on Debian, but the first three
> points are configuration decisions on the part of the NFS server
> administrator. I understand that you have reasons to export shares allowing
> suid binaries in your own environment, but then you can also reconfigure
> root's path or the permissions on /usr/local/* in that case.
Sorry, the NFS server administrator does not really have control over the
first point. The purpose of root_squash is to limit and contain the damage
of a root compromise on the client; if root on the client could be fully
trusted then there would be no need or use for root_squash.
Sorry, as I read Debian policy (and as discussed in #299007), I am not
permitted to change root's PATH or change the permissions on /usr/local.
> I do agree that root should not have directories in its path by default that
> are writable by non-root users; but that is not this bug.
Yes, that is #299007, but am told that policy bugs cannot be critical...
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
