James Carlson wrote: > Glenn Faden writes: > >> Whenever possible we should avoid creating devices in non-global zones. >> Unfortunately, it is possible to panic the kernel from a non-global zone >> if a root process has access to the raw device while it is >> simultaneously mounted as a file system. If you scribble over the >> mounted filesystem you can cause a panic. It is critical to our security >> story to assert that a root process in a non-global zone cannot crash >> the kernel or other zones. >> > > If the inserted device has no recognizable file system on it, or if > the one we recognize cannot be mounted, then we create a device node > in the zone. If it can be mounted, then only the mount point is > inserted in the zone for security reasons. > > But how can this be a complete answer? If the user inserts either a > blank medium or a device with an intentionally damaged file system, he > gets a device node. He can then mount it, scribble on it, and torch > the system. > > Did I miss something? > The policy for how to handle such media is specified in the device_clean script. Customers are free to write their own customized scripts since the interface is stable. In particular, the SRSS 4.0 release includes Sun Ray-specific device_clean scripts. In the case of hot-plugged USB devices they never create a device node in any labeled zone. If the device isn't recognized as mountable, the allocation is denied.
We have other requests coming from our customers to have a per-user fine-grained policy of whether they can do read-only or read-write mounts. The current design supports this because the authorizations for each device are configurable and extensible. We can create separate authorizations for read-only and read-write mounts, and assign one or the other to individual users. The device_clean script can check the authorizations (using auths(1)) and set the appropriate mount options. --Glenn >> Again, that is not the subject of this case. This is about supporting >> device allocation in zones by Sun Ray software. If device allocation in >> standard Solaris is actually important to customers, we could extend the >> functionality in standard Solaris. However, I think that would done >> differently; probably based on HAL and the GNOME Removeable Drives and >> Media application. >> > > It'd be nice if this corner of the world weren't baroque. The only > thing that keeps my hand away from the derail lever is the lack of Sun > Ray engagement in the ARC; I have little expectation that a full > review would be productive. > >
