The “alternate” path you refer to is via procfs. There are environments where procfs is not available to the user.
It is interesting that procfs based reads therefore represent a *different* set of security controls than just getcwd(). This is unfortunate IMO — especially since it isn’t “always” available. I’m not stating that there “is” a security bug, only stating that I can see that it *might* be. Historically this information was unavailable to users in some circumstances. Making it available in all circumstances may be breaking — it might not be too — I don’t know, only think we have to be very very careful. Because the notion of cwd for a process may differ based on how a process got there, and what context it is running in, I would strongly prefer to see that we take very careful care of this, and if we’re going to make it universally available, then let’s do it properly via system call that takes care of any normalization that might be necessary to account for chroot, zones, etc. Stashing this away in procfs feels far less “good” to me. On Thu, Oct 12, 2017 at 6:10 PM Paul B. Henson <[email protected]> wrote: > > From: Garrett D'Amore > > Sent: Wednesday, October 11, 2017 2:11 PM > > > > The security question is whether there is ever a need to suppress access > to > > the cwd. I think there are several cases where this is absolutely valid. > > It would be a security question if there wasn't a simple and easy > alternative method to obtain the exact same information 8-/. Is there > really a point in having a deadbolt on the front door when you can walk 10 > steps to the side and stroll right through the unlocked kitchen door? > > > I do believe Joerg is right here — this represents, as far as I am > concerned, a > > bug in the Samba code. > > There was indeed a bug in the code; it crashed when getcwd failed. That's > how we found the difference in behavior between illumos and other operating > systems. That bug has been fixed, and there are no longer any bugs (that we > know of) in the samba code regarding this. > > The samba code relies upon knowledge of the current working directory in > order to implement security policy. If it is unable to determine the > current working directory, it refuses to perform certain functions. It in > no way assumes getcwd will succeed, or that it will always know what the > current working directory is. It simply makes decisions based on whether or > not it does. > > Of course, this is undesirable behavior for us, as this lack of > functionality is debilitating to our users. And the failure of the getcwd > call is really not providing any security for the system, as if samba just > knew enough to walk 10 steps over to the kitchen door, it could quickly and > easily get the exact same information that getcwd is refusing to give it. > > > In fact, processes can even live without a valid cwd — for example if > > someone forcibly unlinks the directory. This isn’t even all that > unusual — I > > have left my own shells in that on occasion. > > Well, obviously nonexistence of a cwd is a different state than inability > to read the path of an existing one. Interestingly, it seems getcwd() > returns ENOENT in that case, which isn't even documented as a possible > error value in getcwd(3c). > > The bottom line is that other major operating systems, not only Linux and > the BSD's, but also Solaris 11 and the most recent 10, no longer return > access denied for the getcwd call if a component of the path lacks read > permission. The latest POSIX standard has changed the definition from SHALL > to MAY for that error code. Given under illumos the same information is > available via a different avenue, it's hard to buy a "but the security" > argument for not updating illumos to the same behavior. I understand there > are potentially other things to consider in illumos such as zones, etc, but > presumably those same considerations were made in Solaris for the change, > and while I most certainly would never be one to advocate let's just play > follow the leader with Oracle, my understanding is that those changes were > made by Casper Dik, and I definitely would trust he appropriately evaluated > them before they were implemented. > ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T1bf578bf66b8b8b0-M112994d2e4a3a9fc8c0f0d82 Powered by Topicbox: https://topicbox.com
