jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) (06/12/91)
If a file system is exported without root permissions then NFS requests from user "root" (0) get translated into "nobody" (-2). So, NFS access looses not only the root privilege of writing any file but also the ability to write to files owned by root on the server. This much is documented behavior. But, if the permissions of root, translated into nobody, fail should not the group permissions take effect? For example if I am running as root with group permissions of wheel or staff should I not be able to create a file in a directory that has group write for that group? In fact every test that I have run indicates that group permissions are ignored and only "other" permissions are allowed. While it seems reasonble to block root from special privileges across NFS it does not seem reasonable that root should have less privilege than a normal user. There is no security benefit derived from this behavior. The remote root user could su to any uid or guid they chose and get the owner or group access desired. I had attempted to set up a directory with shared access from several different systems. Making the directory group write-able worked OK for normal user access but failed for root access. Jerry
brent@terra.Eng.Sun.COM (Brent Callaghan) (06/13/91)
In article <50868@olivea.atc.olivetti.com>, jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) writes: > If a file system is exported without root permissions then NFS requests > from user "root" (0) get translated into "nobody" (-2). So, NFS access > looses not only the root privilege of writing any file but also the > ability to write to files owned by root on the server. This much is > documented behavior. > > But, if the permissions of root, translated into nobody, fail should not > the group permissions take effect? For example if I am running as root > with group permissions of wheel or staff should I not be able to create > a file in a directory that has group write for that group? In fact > every test that I have run indicates that group permissions are ignored > and only "other" permissions are allowed. The server maps the credentials of uid 0 (root) to the credentials of uid -2 (nobody). Since the gid is part of the credentials - you are also picking up the gid of nobody. > While it seems reasonble to block root from special privileges across > NFS it does not seem reasonable that root should have less privilege > than a normal user. There is no security benefit derived from this > behavior. The remote root user could su to any uid or guid they chose > and get the owner or group access desired. I agree that Unix credentials are easy to spoof if you're root on the client, though I don't agree that there's no security benefit in doing the mapping. It's pretty effective at limiting access to files with permissions restricted to root. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems Email: brent@Eng.Sun.COM phone: (415) 336 1051
geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (06/13/91)
[On why mapping root to -2 also maps the gid] If you don't trust the root uid, why would you trust a gid that the root might have given him/herself? Geoff --Geoff Arnold, PC-NFS architect(geoff@East.Sun.COM or geoff.arnold@Sun.COM)-- ------------------------------------------------------------------------------ -- Sun Technology Enterprises : PC Networking group -- -- (officially from July 1, but effectively in place right now) --
richard@aiai.ed.ac.uk (Richard Tobin) (06/19/91)
In article <6720@eastapps.East.Sun.COM> geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: >If you don't trust the root uid, why would you trust a >gid that the root might have given him/herself? For the same reason that you trust a non-root uid that root gives itself. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
rbraun@spdcc.COM (Rich Braun) (06/20/91)
geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: >>If you don't trust the root uid, why would you trust a >>gid that the root might have given him/herself? richard@aiai.UUCP (Richard Tobin) writes: >For the same reason that you trust a non-root uid that root gives >itself. You're overlooking one thing: if you have two systems A and B, and a root user on B su's to some other uid, he now has access to files on system A under that new uid. Yet system A didn't grant the access. This is a security hole under all Unix NFS implementations, as far as I know. It means people can't be given the root password to their own office workstations! -rich
db@argon.Eng.Sun.COM (David Brownell) (06/20/91)
In article <7958@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: > You're overlooking one thing: if you have two systems A and B, and > a root user on B su's to some other uid, he now has access to files on > system A under that new uid. Yet system A didn't grant the access. Highly dependant on an administrative policy that system A could have changed if its administrator/owner wanted ... > This is a security hole under all Unix NFS implementations, as far > as I know. Secure NFS, available on SunOS 4.0 (and later) and in UNIX SVr4, has addressed this problem. Export the file system 'secure'; some other configuration will be required, as well. It's the same NFS protocol, but requires a better authentication system. - Dave
richard@aiai.ed.ac.uk (Richard Tobin) (06/25/91)
In article <7958@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >richard@aiai.UUCP (Richard Tobin) writes: >>For the same reason that you trust a non-root uid that root gives >>itself. >You're overlooking one thing: if you have two systems A and B, and >a root user on B su's to some other uid, he now has access to files on >system A under that new uid. I wasn't overlooking it; it was the point of my posting. Given that root can gain access to any other user's files in this way, there's no point not trusting root's groups. As I've commented before, this also means it's pointless to not let root just go ahead and access files that any non-root local user could access. The only thing it really prevents is a remote root doing things that only root could do locally. This misfeature, coupled with stupid client caching, leads to this persistent annoyance, which is still in SunOS 4.1.1: skye# ls -l xyz -rw------- 1 richard 6 Jun 24 19:47 xyz [xyz is on a remote file system] skye# cat xyz cat: write error: Permission denied [this error message is of course another bug] skye% cat xyz cat: write error: Permission denied [and now I can't read my own file!] -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
jim@cs.strath.ac.uk (Jim Reid) (06/26/91)
In article <15542@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes:
Secure NFS,... has addressed this problem.
Secure NFS is an oxymoron.
It's the same NFS protocol, but requires a better authentication system.
It has a better authentication system, but not much better. For one
thing, NIS (Yellow Pages) is used to distribute the keys. You might as
well announce those keys on peak-time TV for all the "security" NIS
offers. For another, the actual file data being read or written is not
encrypted. It still gets passed in cleartext. Finally, the so-called
secure NFS requires DES hardware to work at reasonable speed. This
makes it almost unusable outside the USA because Uncle Sam doesn't
want the rest of the world to have access to DES hardware.
Secure NFS is a bit like finding that the bank vault is made of cheap
cardboard: from a distance it looks OK, but a close inspection reveals
the horrible truth.
Jimdb@argon.Eng.Sun.COM (David Brownell) (06/27/91)
Recently, jim@cs.strath.ac.uk (Jim Reid) flamed "Secure NFS". It's not perfect (is anything?), but some of his comments were off base: > It has a better authentication system, but not much better. For one > thing, NIS (Yellow Pages) is used to distribute the keys. You might as > well announce those keys on peak-time TV for all the "security" NIS > offers. Of course, that's the virtue of a public key encryption system: you can distribute the public keys freely, like on a CD-ROM (or even on TV! :-), and it doesn't matter. This isn't a valid criticism. Ask sci.crypt how exponential key exchange works. > For another, the actual file data being read or written is not > encrypted. It still gets passed in cleartext. This wasn't the problem originally being discussed, it was the ease of spoofing servers. Providing confidentiality is hard because of the US export controls on encryption technology. I can't think of ANY widely used network system that's secure against eavesdroppers. The market in this area has been restrained. > Finally, the so-called > secure NFS requires DES hardware to work at reasonable speed. This > makes it almost unusable outside the USA ... Speed wasn't the point ... but I'm not sure I'd agree, either. A few years ago, I set up a bunch of 2 MIPS machines to use Secure NFS using an exportable OS release and no DES hardware. They were slower, but quite usable. (I know, "reasonable" is subjective! Let's say I just took slightly longer coffee breaks after typing "make".) > ... Uncle Sam doesn't > want the rest of the world to have access to DES hardware. .... or DES software for that matter. If you're a US citizen and care about this, write your congress(wo)men about this one. There's a chance that some of this stuff can change over the next few years: there are going to be some hearings later this year (Senat Judiciary?) about privacy and technology. Encourage Congress to move this stuff off the munitions list! - Dave #include <std/disclaimer.H>
jim@cs.strath.ac.uk (Jim Reid) (06/27/91)
In article <15886@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes: Recently, jim@cs.strath.ac.uk (Jim Reid) flamed "Secure NFS". It's not perfect (is anything?), but some of his comments were off base: > It has a better authentication system, but not much better. For one > thing, NIS (Yellow Pages) is used to distribute the keys. You might as > well announce those keys on peak-time TV for all the "security" NIS > offers. Of course, that's the virtue of a public key encryption system: you can distribute the public keys freely, like on a CD-ROM (or even on TV! :-), and it doesn't matter. This isn't a valid criticism. Ask sci.crypt how exponential key exchange works. I do understand how public key encryption works. What you have overlooked is that secure NFS uses NIS to store the secret keys as well as the public keys (at least that's what TFM says.....). What's to stop me from firing NIS lookup requests at the genuine server and taking the replies away for cryptanalysis? [Let's assume that someone has had the sense to make /etc/publickey world unreadable.] What's to stop me from firing bogus NIS keyserv updates at the NIS server from somewhere that I've improperly obtained root privileges? If that sounds too much like hard work, what if I set up a bogus NIS server somewhere on the net and use ypset to direct all NIS lookups at my bogus host? Jim