On Fri, Feb 27, 2009 at 07:29:14PM -0500, Sebastien Roy wrote: > > On Fri, 2009-02-27 at 15:30 -0800, Edward Pilatowicz wrote: > > On Wed, Feb 25, 2009 at 08:15:53AM -0500, Sebastien Roy wrote: > > > Okay. The other issue that Ed brought up with reaching inside a > > > non-global zone's filesystem to update or read a file was not related to > > > SMF. It's that paths within the zone can't be trusted due to the > > > potential for a malicious admin within the zone having munged the zone's > > > filesystem to foil the global dlmgmtd process. Since this would only > > > affect that local zone's configuration, I'm not sure how much of a > > > concern this is. Ed, perhaps you can expand on this particular concern > > > to help me better understand it. > > > > > > > opening files in running zones can be problematic. the problem is that > > you can't trust the contents of the zone to be what you expect. a > > hostile zone administrator could change any path component within the > > zone. > > Okay, this is the part I'd like to understand better. How could the > rogue administrator hurt anyone other than himself in this case? He > can't create links from his local zone's /etc/dladm/datalink.conf to > other zone's files, right? ...
wrong. if you creat a symlink within a zone, say /foo -> /bar, and the you open that symlink from within a zone. it is resolved relative to that zones root. but if you open <zoneroot>/foo from the global zone, the symlink is resolved relative to the global zone, so you'll get /bar in the global zone. another example. if we have the following symlink in a zone /foo -> ../../../../../../../../foo, within the zone that is a recursive symlink. from the global zone it isn't. > ... If an unusable zone is the worst that can > happen, how would this be any different from the same rogue > administrator simply writing garbage in the /etc/dladm/datalink.conf > file? > > I think I'm probably missing the threat model you're describing. > in the example above, the zoneadm could replace /etc/dladm with a symlink who's target is /etc/dladm. then instead of updating the zones configuration you would update the global zones config. oops. > > if a zone isn't running, then you can inspect each component of the file > > you're trying to access to verify that it is indeed the file you think > > you're accessing before openeing the file. in a running zone, this > > doesn't work since there is no way to do this check and then open the > > file atomically. (afaik, there is also no way to open the file and then > > do this check on the opened file descriptor.) > > Granted this is all true. I still need to understand why we should care > if a zone administrator trashes his zone. He could rm -rf /kernel also, > and that would be pretty effective. > actually, all zones on a system run on the same kernel, and kernel modules are only loaded from the global zone. so your example above has no impact if run within a zones. i think the effect that your trying to achive could be better acomplished by doing "rm -f /lib/ld.so.1" or "rm -f /lib/libc.so.1". > > hence, if you want to access a file in a running zone, i would strongly > > recommend that you open the file from within the zone, either by having > > a process already inside the zone open the file or by having a process > > enter the zone and open the file. once the file has been opened from > > within the zone you can pass the file descriptor for the file back to > > the global zone. > > But the local process running from within a running zone is just as > vulnerable to a symbolic link'ed /etc/dladm/datalink.conf in the zone, > right? I must be missing the essence of what you're saying. > nope. as previously mentioned, symbolic links are resolved relative to the current processes zones root, and processes within a zone can't "cd .." out of their root directory. ed
