Re: Labeled NFS [v5]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm not sure what the proposed hook would be for except to identify it
as concerned with nfs. Perhaps the hook could return the names of
attributes that it wants nfs to provide.


I'm not quite sure what you're proposing? I'm sure someone would find
another use for this hook though. The inode_getsecctx hook we made for
Labeled NFS was already merged because it was needed for providing
"persistent" label support for sysfs (meaning that it persisted inode
eviction from memory). The problem is that we have no real way to ask in
the NFS code if this is an LSM that can be used with Labeled NFS. In the
xattr code we have the new ismaclabel hook we add which allows us to
verify the xattr used as belonging to a label based LSM however we need
an xattr from userspace for that. The reason this is required is that
the server will need to fill out its capability mask to indicate it
supports security labeling. In addition the client also needs to know if
its running a security label based LSM because it will need to mask out
the label fattr bit from its getattr calls if it doesn't support it. We
can override this in SELinux by giving it a context mount but if we
don't then it will need to know whether or not to be pulling security
labels back.



I think the point I'm trying to make is that we need to define the interface which if you implement it you are supported. For label import/export we have inode_{get,set,notify}secctx. For checking for xattr suitibility we have the new ismaclabel lsm call. Now the final thing we need to do is a call to determine if the lsm is suitable for Labeled NFS export meaning that it agrees to the semantics. Is inode{get,set,notify}_secctx and ismaclabel sufficient? I'm tempted to say we can make a call to inode_getsecctx and if it failes with EOPNOTSUPP we say we don't support it but then we need an initial file to call that on. This is why I'd rather have a LSM call that we can make that gives us a yes/no answer.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux