Bug#384922: nfs-kernel-server: root_squash is broken
retitle 384922 please support NFS squashing multiple groups reassign 384922 linux-2.6.16 thanks On Wed, Aug 30, 2006 at 10:31:57AM +1000, Paul Szabo wrote: Are you saying that mountd might be happy to squash gid=staff, but the kernel would not understand such a request? Yes. Or rather, there is no way to tell the kernel that, so nfs-utils doesn't try to. (All the other code is there, though -- even the man page is written.) OK, how about: make a wishlist for NFS to squash gid=staff as default with root_squash, and reassign to the kernel to support that? Please do any of the above as you see fit. Done. (You may want to actually talk to the NFS kernel server people about that, though; I doubt such a bug in Debian's BTS will be read by them.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
retitle 384922 NFS insecure without support for squashing multiple groups tags 384922 security severity 384922 critical thanks Dear Steinar, ... You may want to actually talk to the NFS kernel server people ... Huh? I thought that is what have I been doing until now! (Oops, my mistake, package nfs-kernel-server does not come close...) Funny: you meekly accept that NFS is hopelessly insecure and no security conscious person will ever use it. Do you not find that offensive? (Not my comment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299007;msg=276 .) Funny: all it would take is a tiny policy change, to be permitted to drop /usr/local things from root's PATH, or to remove group staff writability from those things. Everyone seems to know those should be done... Thanks for your help, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
On Mon, Aug 28, 2006 at 08:39:41AM +1000, Paul Szabo wrote: There is a warning in man exports against other sensitive UIDs, but not against sensitive GIDs. There are no sensitive UIDs on a default Debian installation, but there is a sensitive GID mandated by policy; there is no default or easy gid_squash on NFS exports. The intended security benefit of root_squash is defeated. (This is not really a bug in NFS, but a result of broken policy; maybe NFS could document the issue, or help change policy.) I'm not sure how you think this is supposed to be solved, but about no matter what, this is the wrong package. nfs-utils doesn't do any of the squashing; it's just the part responsible for setting up the mount and that's it. If you really think more than one gid should be squashed, you should reassign to the kernel -- if you think this is a policy bug, you should reassign to the policy package. The only thing I could think of changing in nfs-utils (except support an updated interface for gid squashing) would be documentation, in which case this is wishlist. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
On Wed, Aug 30, 2006 at 08:12:45AM +1000, Paul Szabo wrote: ... this is the wrong package. nfs-utils doesn't do any of the squashing ... I submitted the bug against nfs-kernel-server. I do not understand why you think nfs-utils is involved. nfs-kernel-server is part of nfs-utils. Again: nfs-utils only contains the userspace part, which has no say in this. Sensible people would fix the brain-dead policy. In the face of existing policy, the NFS packages should do their best to protect the innocent: big warnings in man pages That would be a wishlist bug. maybe squashing the bad guys (i.e. squash gid=staff also when doing root_squash). nfs-utils cannot do such a thing without having the kernel changed first. The way things are, root_squash is documented as being useful, which it is not: because it can be defeated, its intentions circumvented. Assuming a combination of all of: 1. You have a compromised machine which you trust. 2. You are exporting file systems which are not set to nosuid, read-write. 3. You have /usr/local/* in your path (note that it's not in root's path by default, so you cannot easily make root run these; and if you have root on a compromised machine, you can just as well make suid files pointing to _any_ user, and then trojanize their home directory or whatever, so being gid=staff really won't help you much). 4. You can login on the NFS server. This is not an impossible combination, but it's not a gaping security hole either. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
Dear Steinar, ... this is the wrong package. nfs-utils doesn't do any of the squashing ... I submitted the bug against nfs-kernel-server. I do not understand why you think nfs-utils is involved. I'm not sure how you think this is supposed to be solved ... Sensible people would fix the brain-dead policy. In the face of existing policy, the NFS packages should do their best to protect the innocent: big warnings in man pages, maybe squashing the bad guys (i.e. squash gid=staff also when doing root_squash). The way things are, root_squash is documented as being useful, which it is not: because it can be defeated, its intentions circumvented. You may think of this as just a documentation issue, that things will be fine if you document that root_squash is useless. That may be an abrogation of responsibility: try explaining but it was in the man page to someone who just had his machine trashed because he trusted root_squash. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
On Wed, Aug 30, 2006 at 09:19:37AM +1000, Paul Szabo wrote: One of us is confused. Given that one of us has been co-maintaining nfs-utils for a while, I think I might have an idea :-) Squash is set in /etc/exports, I think /etc/exports is used by mountd; surely it is all done here? mountd never serves a single file. All it does is receive a mount request, authenticate it and then hand it off to the kernel. It cannot do a thing with squashing if the kernel doesn't support it. Note that nfs-utils _has_ code in place for parsing gid lists and the like; you can even specify squash_gids=. However, it is not documented for a simple reason: it _does not work_, since the kernel exports no such interface. 1. You have a compromised machine which you trust. Do not trust. Full trust would not need root_squash. root_squash is a safety net. It is _not_ a trust measure. 2. You are exporting file systems which are not set to nosuid, read-write. Whether suid or not on the NFS client is irrelevant. Yes, I was talking about the server. You could protect by, on the NFS exporter, mount nosuid the filesystem containing the exported directory. Yes. Do you really not put nosuid on your /home? Now supposing this contains user home directories, you will want to export read/write; you will want to mount suid on the NFS client, and if you allow user logins to the server also then will want suid there also. Then I'm afraid you have different wants than me. I definitely do not want /home nosuid, and I can't really imagine too many other sane administrators wanting to. My exact situation: my home directory is exported from a server (read/write and suid everywhere), with user login access to the server also. Gaping. Mount the file systems nosuid on the server, don't trust hosts you shouldn't trust. You can easily configure a system insecurily if you really want to; that doesn't really have to mean that anything is buggy. Anyhow, you'll have to decide: Either close, reassign to the kernel, or retitle to something like please document that root_squash doesn't squash gid staff and set to wishlist -- even leaving aside the other issues, that's really all nfs-utils can do here. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
Dear Steinar, nfs-kernel-server is part of nfs-utils. Again: nfs-utils only contains the userspace part, which has no say in this. One of us is confused. Checking: $ dpkg -I nfs-kernel-server_1.0.6-3.1_i386.deb ... Description: Kernel NFS server support ... $ dpkg -c nfs-kernel-server_1.0.6-3.1_i386.deb ... -rwxr-xr-x root/root 2356 2003-08-04 11:38:55 ./etc/init.d/nfs-kernel-server -rw-r--r-- root/root 114 2005-01-05 23:38:17 ./etc/exports ... -rwxr-xr-x root/root 35928 2005-01-05 23:44:03 ./usr/sbin/exportfs -rwxr-xr-x root/root 60280 2005-01-05 23:44:03 ./usr/sbin/rpc.mountd -rwxr-xr-x root/root 5148 2005-01-05 23:44:03 ./usr/sbin/rpc.nfsd ... Squash is set in /etc/exports, I think /etc/exports is used by mountd; surely it is all done here? Assuming a combination of all of: 1. You have a compromised machine which you trust. Do not trust. Full trust would not need root_squash. 2. You are exporting file systems which are not set to nosuid, read-write. Whether suid or not on the NFS client is irrelevant. You could protect by, on the NFS exporter, mount nosuid the filesystem containing the exported directory. Now supposing this contains user home directories, you will want to export read/write; you will want to mount suid on the NFS client, and if you allow user logins to the server also then will want suid there also. (I note that if you always mount nosuid those filesystems that contain read/write exported directories, then you may not need root_squash at all.) 3. You have /usr/local/* in your path (note that it's not in root's path by default, so you cannot easily make root run these; and if you have root on a compromised machine, you can just as well make suid files pointing to _any_ user, and then trojanize their home directory or whatever, so being gid=staff really won't help you much). Kindly test on a Debian machine. The presence of /usr/local/bin in root's PATH is mandated by policy. My original bug report #299007 (in more innocent times) was exactly about that PATH setting. 4. You can login on the NFS server. This is not an impossible combination, but it's not a gaping security hole either. My exact situation: my home directory is exported from a server (read/write and suid everywhere), with user login access to the server also. Gaping. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
Dear Steinar, ... I think I might have an idea :-) Good. Note that nfs-utils _has_ code in place for parsing gid lists and the like; you can even specify squash_gids=. However, it is not documented for a simple reason: it _does not work_, since the kernel exports no such interface. Are you saying that mountd might be happy to squash gid=staff, but the kernel would not understand such a request? Then I'm afraid you have different wants than me. I definitely do not want /home nosuid, and I can't really imagine too many other sane administrators wanting to. My users demand it. A few create suid-to-themselves applications to let people submit data to them. Anyhow, you'll have to decide: Either close, reassign to the kernel, or retitle to something like please document that root_squash doesn't squash gid staff and set to wishlist -- even leaving aside the other issues, that's really all nfs-utils can do here. OK, how about: make a wishlist for NFS to squash gid=staff as default with root_squash, and reassign to the kernel to support that? Please do any of the above as you see fit. I was actually hoping that the NFS community would be able to convince the policymakers to fix the policy. They tricked you already: you were mistaken about root's PATH. With the wrong policy, bugs such as this will keep popping up; they will be reassigned, retitled, or otherwise shifted without actually solving anything; and the holes will remain. Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
Package: nfs-kernel-server Version: 1:1.0.6-3.1 Severity: critical Justification: root security hole NFS uses root_squash by default, in part (mainly?) so as to make it more difficult to create a setuid-root file in a writable export: protect the exporting server from a compromise of the mounting client. With Debian policy, group staff is root-equivalent: an evil client could create a setgid-staff file, and with that trojanize /usr/local/bin (drop a suitable ls or xterm or bash file). There is a warning in man exports against other sensitive UIDs, but not against sensitive GIDs. There are no sensitive UIDs on a default Debian installation, but there is a sensitive GID mandated by policy; there is no default or easy gid_squash on NFS exports. The intended security benefit of root_squash is defeated. (This is not really a bug in NFS, but a result of broken policy; maybe NFS could document the issue, or help change policy.) Please see also bug#299007 http://bugs.debian.org/299007 . Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-spm1.5 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages nfs-kernel-server depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii nfs-common 1:1.0.6-3.1 NFS support files common to client ii sysvinit2.86.ds1-1 System-V like init -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384922: nfs-kernel-server: root_squash is broken
Please see also http://lists.grok.org.uk/pipermail/full-disclosure/2006-August/049079.html Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
