...
4.  Mounting lofi devices

     The direct mount support introduced in PSARC 2008/290 works as
     expected in non-global zones.

     Allowing lofi devices into non-global zones introduces a security
     issue. Some filesystems (notably UFS) are not sufficiently protected
     against corrupted or maliciously constructed filesystem images,
     which lofi allows the zone root user to modify. This could
     potentially lead to a non-global zone panicking the kernel.

     Therefore, mounts within a non-global zone are restricted to a
     given allowed list of filesystems, as described in Section 5 and
     Section 6. This applies to all mounts not just lofi ones.

5.  New vfs flag VSW_ZMOUNT

     The default list of allowed filesystems is based upon a new vfsdef_t
     flag VSW_ZMOUNT. If set, then the filesytem may be mounted within a
     zone, regardless of the fs-allowed value.

     This flag is Consolidation Private.

     Today, this flag is set for pseudo filesystems such as proc, network
     filesystems such as NFS, plus the hsfs filesystem. Future work may
     enable other filesystems by default.

     Currently, a non-global zone can create a ZFS volume, but it is not
     visible inside the zone's /dev.  This case doesn't attempt to fix
     this, although future work may enable it.

6.  fs-allowed zone property

     Although we cannot guarantee the safety of this, this case also
     defines a new zone property to allow the administrator to add
     filesystems to this approved list. The property "fs-allowed" is a
     list of filesystem names that may be mounted from within the zone,
     in addition to the ones already allowed. For example, to also allow
     access to pcfs and ufs mounts:

     # zonecfg -z ozone
     zonecfg:ozone>  set fs-allowed=ufs,pcfs

     This property does not affect zone mounts administrated by the
     global zone via "add fs" or "add dataset".

     This property applies to all zone brands except lx, where it is not
     allowed to be set.

     This propety is Committed.


It would seem that (6) is at odds with (4) because (6) does not
allow you to restrict which filesystems the flag defined by (5)
is applied to. Or at least that's the impression I get from the
example, which seems at odds with the description. For example,
if you do "man filesystem", it talks about things like / and /usr.
Yet here "filesystem" seems to mean the type of filesystem.

Could you please expand on what is actually meant here?
Is "fs-allowed" for _filesystems_ or _types of filesystems_?

And whilst the question posed by (4) is correct, what I'm
looking for is an example of how to specify which filesystems
can be safely used inside the zone under the assumption that
there could be bugs in the implementation of any type of
filesystem that leads to a "failure" but that not all filesystems
are problematic.

For example, how do I allow a local zone to use lofiadm to
access a ufs filesystem that is in the form of a single file
image but at the same time disallow lofiadm to present a ufs
image on a usb thumbstick or via nfs?

btw, I'll say in advance that if the project doesn't solve
the problem of allowing particular images or filesystems
being usable by lofiadm, then that's ok with me: just please
make the wording more explicit about what is really meant.

Darren

_______________________________________________
opensolaris-arc mailing list
[email protected]

Reply via email to