Concerning ZFS dataset properties for OS-specific mount options

[Richard Yao]

Dear Everyone,

SELinux is an extension to the Linux kernel that implements
"label-related mount options and extensions to the mount table" (to
quote Oracle).

http://www.oracle.com/technetwork/systems/articles/mls-trusted-exts-jsp-136451.html

SELinux refuses to permit ZFS datasets to mount unless it is passed
appropriate labels. This can be worked around by using legacy mount
options, but that is suboptimal.

http://comments.gmane.org/gmane.comp.security.selinux/19368
https://github.com/zfsonlinux/zfs/issues/1504

Specifically, SELinux introduces four label-related mount options:

context=label
fscontext=label
rootcontext=label
defcontext=label

Details concerning the label grammar for those who are interested are
likely buried in RedHat's documentation. I will need to understand the
label grammar so that I can implement validation alongside a method for
handling it, but that is something to worry about after I decide how to
handle this.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-SELinux_Contexts.html

I have thought of a few ways of handling this.

1. Abusing the mlslabel property and permitting people to `zfs set
mlslabel=context=label,fscontext=label,rootcontext=label,defcontext=label`.
This would prevent us from doing inheritance on Linux and probably cause
problems for people who import pools previously used with SELinux on
Illumos.

2. Making a new selinux= property that would use the syntax from #1, but
this would still prevent inheritance.

3. Making a bunch of new selinux-context, selinux-fscontext,
selinux-rootcontext, selinux-defcontext dataset properties. This is
better in that inheritance can handled whichever way we find to be
appropriate, but they are Linux-specific. Being in the general namespace
will prevent them from being carried by streams (is this desireable?)
and they will be something of an artifact that cannot be removed should
a pool that has this set be imported on another system (possibly
undesireable).

4. Reserving the selinux: subset of the user property namespace and
creating selinux:context, selinux:fscontext, selinux:rootcontext,
selinux:defcontext options. They would be treated as user properties on
other implementation. On Linux, we could do proper inheritance and apply
these settings when doing non-legacy mounts when SELinux is available. I
believe that they would be preserved by replication streams, although I
should double check that.

Right now, I am leaning toward option 4, but I am okay with option 3 if
other implementations are okay with it. What do other people think about
this? Are there any better alternatives that I missed?

Yours truly,
Richard Yao




-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Matthew Ahrens]

Post by Richard Yao
Dear Everyone,
SELinux is an extension to the Linux kernel that implements
"label-related mount options and extensions to the mount table" (to
quote Oracle).
http://www.oracle.com/technetwork/systems/articles/mls-trusted-exts-jsp-136451.html
SELinux refuses to permit ZFS datasets to mount unless it is passed
appropriate labels. This can be worked around by using legacy mount
options, but that is suboptimal.
http://comments.gmane.org/gmane.comp.security.selinux/19368
https://github.com/zfsonlinux/zfs/issues/1504
context=label
fscontext=label
rootcontext=label
defcontext=label
Details concerning the label grammar for those who are interested are
likely buried in RedHat's documentation. I will need to understand the
label grammar so that I can implement validation alongside a method for
handling it, but that is something to worry about after I decide how to
handle this.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-SELinux_Contexts.html
I have thought of a few ways of handling this.
1. Abusing the mlslabel property and permitting people to `zfs set
mlslabel=context=label,fscontext=label,rootcontext=label,defcontext=label`.
This would prevent us from doing inheritance on Linux and probably cause
problems for people who import pools previously used with SELinux on
Illumos.

Yeah, probably a bad idea for cross-platform compatibility.

Post by Richard Yao
2. Making a new selinux= property that would use the syntax from #1, but
this would still prevent inheritance.

Can you clarify on if inheritance is desired (I don't know much about
selinux), and why this would prevent inheritance? Certainly the property
could be inherited the same as any other inheritable property (e.g.
compression, mlslabel).

Post by Richard Yao
3. Making a bunch of new selinux-context, selinux-fscontext,
selinux-rootcontext, selinux-defcontext dataset properties. This is
better in that inheritance can handled whichever way we find to be
appropriate, but they are Linux-specific. Being in the general namespace
will prevent them from being carried by streams (is this desireable?)

I don't think that's true; we should send all modifiable properties. See
send_iterate_prop(). If the receiving system doesn't understand the
property, then it should print a warning message and continue.

and they will be something of an artifact that cannot be removed should

Post by Richard Yao
a pool that has this set be imported on another system (possibly
undesireable).

I don't think that will create any problem. Properties can be added
without changing the on-disk format, if they can be safely ignored by
software that doesn't understand them. That should be the case here.

Post by Richard Yao
4. Reserving the selinux: subset of the user property namespace and
creating selinux:context, selinux:fscontext, selinux:rootcontext,
selinux:defcontext options. They would be treated as user properties on
other implementation. On Linux, we could do proper inheritance and apply
these settings when doing non-legacy mounts when SELinux is available. I
believe that they would be preserved by replication streams, although I
should double check that.
Right now, I am leaning toward option 4, but I am okay with option 3 if
other implementations are okay with it. What do other people think about
this? Are there any better alternatives that I missed?

I think options #3 or #4 are fine. #3 seems most similar to the way
mlslabel is handled on illumos. If you go with #4, I'd suggest sticking
with the reverse-dns property naming scheme, meaning
"org.selinuxproject:context", etc.

--matt



-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Richard Yao]

Post by Matthew Ahrens

Post by Richard Yao
2. Making a new selinux= property that would use the syntax from #1, but
this would still prevent inheritance.

Can you clarify on if inheritance is desired (I don't know much about
selinux), and why this would prevent inheritance? Certainly the property
could be inherited the same as any other inheritable property (e.g.
compression, mlslabel).

There are 4 different properties being mapped to the same one. It is
possible to do inheritance on the ones where that is desireable, but
that would be confusing to end-users. The way that doing inheritance
here would work would be to make
selinux=fscontext=<label>,context=<label> become
selinux=fscontext=<label> on inherited datasets.

To be clear, this is just an example. I have some other things in the
pipeline before this one, so I have not decided upon how the inheritance
should be done yet, but the point is that we probably want only some of
these labels to be inherited.

Post by Matthew Ahrens

Post by Richard Yao
3. Making a bunch of new selinux-context, selinux-fscontext,
selinux-rootcontext, selinux-defcontext dataset properties. This is
better in that inheritance can handled whichever way we find to be
appropriate, but they are Linux-specific. Being in the general namespace
will prevent them from being carried by streams (is this desireable?)

I don't think that's true; we should send all modifiable properties. See
send_iterate_prop(). If the receiving system doesn't understand the
property, then it should print a warning message and continue.
and they will be something of an artifact that cannot be removed should

Post by Richard Yao
a pool that has this set be imported on another system (possibly
undesireable).

I don't think that will create any problem. Properties can be added
without changing the on-disk format, if they can be safely ignored by
software that doesn't understand them. That should be the case here.

That is great to hear.

Post by Matthew Ahrens

Post by Richard Yao
4. Reserving the selinux: subset of the user property namespace and
creating selinux:context, selinux:fscontext, selinux:rootcontext,
selinux:defcontext options. They would be treated as user properties on
other implementation. On Linux, we could do proper inheritance and apply
these settings when doing non-legacy mounts when SELinux is available. I
believe that they would be preserved by replication streams, although I
should double check that.
Right now, I am leaning toward option 4, but I am okay with option 3 if
other implementations are okay with it. What do other people think about
this? Are there any better alternatives that I missed?

I think options #3 or #4 are fine. #3 seems most similar to the way
mlslabel is handled on illumos. If you go with #4, I'd suggest sticking
with the reverse-dns property naming scheme, meaning
"org.selinuxproject:context", etc.

Thanks. :)





-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com