On 8/8/2024 1:53 PM, Paul Moore wrote: > On Thu, Aug 8, 2024 at 7:59 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: >> On Wed, Aug 7, 2024 at 1:02 PM Stephen Smalley >> <stephen.smalley.work@xxxxxxxxx> wrote: >>> On Tue, Aug 6, 2024 at 12:56 PM Stephen Smalley >>> <stephen.smalley.work@xxxxxxxxx> wrote: >>>> With these changes applied, the following sequence works to >>>> demonstrate creating a new SELinux namespace: >>>> # Ask to unshare SELinux namespace on next exec >>>> $ echo 1 > /sys/fs/selinux/unshare >>>> # Unshare the mount and network namespaces too. >>>> # This is required in order to create our own selinuxfs mount for the >>>> # new namespace and to isolate our own SELinux netlink socket. >>>> $ unshare -m -n >>>> # Mount our own selinuxfs instance for our new SELinux namespace >>>> $ mount -t selinuxfs none /sys/fs/selinux >>>> # Load a policy into our SELinux namespace >>>> $ load_policy >>>> # Create a shell in the unconfined user/role/domain >>>> $ runcon unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 /bin/bash >>>> $ setenforce 1 >>>> $ id >>>> uid=0(root) gid=0(root) groups=0(root) >>>> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>>> >>>> NB This new namespace is NOT currently confined by its parent. And >>>> there remain many unresolved issues. >>> A couple of additional changes pushed, one to fix a bug in the inode >>> handling and another to introduce support for revalidating superblock >>> SIDs and updating them as needed for the namespace. With these >>> changes, the selinux-testsuite filesystem-related tests appear to pass >>> within a new SELinux namespace. Other tests vary - some pass, some >>> fail, some hang. >> I think before we proceed further with the SELinux namespaces support, >> we need to decide on how we are going to handle SIDs since that has a >> significant impact on the approach. There are (at least) two options: >> 1) SIDs are maintained per-namespace; this is the current approach in >> the patch series since the existing SELinux SID table (sidtab) is >> actually a mapping from SIDs to security context structures, not >> strings (with the exception of undefined contexts with the deferred >> mapping support), where the structures contain the policy indices for >> the relevant user/role/type/level. >> 2) SIDs are maintained globally, e.g. we introduce a new SID table >> outside of the security server that maps SIDs to security context >> strings (hence policy-independent). This would be more akin to Smack's >> known label list that is also used to assign SIDs, and would provide a >> stable pointer for context strings that could be cached in the inode >> security blobs without needing to maintain per-inode copies of the >> context strings. >> >> I started with approach #1 because that was how the existing SID table >> works within SELinux. However, approach #2 has a number of advantages: >> - It matches the LSM hook interface handling of secids, which assume >> that secids are global identifiers and allows kernel data structures >> outside of LSM to cache and pass secids back into the LSM later, e.g. >> for audit and networking. >> - It avoids the need to revalidate and re-map SIDs in the object >> security blobs prior to each use since they would be global, >> eliminating the complexity associated with >> __inode_security_revalidate(), sbsec_revalidate(), and doing the same >> for all the remaining object security blobs. >> - It would remove the need to instantiate the network SID caches >> (netif, netnode, netport) per-namespace. >> - It would potentially allow for a global AVC (currently >> per-namespace) aside from the question of how to handle the policy >> seqno and when to flush the AVC (e.g. introduce a global policy seqno >> that is incremented on any reload in any namespace?). >> >> Given these advantages, I am inclined to switch to approach #2. Thoughts? > I agree. I gave this some thought when I was thinking about how to > handle persistent storage and I think adopting option #2 (global SIDs) > would help simplify things significantly. You can achieve a significant performance improvement as well if we change the SID interfaces to use pointers into the SID table instead of SIDs. v39 of the stacking patch set included a struct lsmblob that would make this easy. Alas, there remain some networking interfaces that will require u32 SID interfaces for the foreseeable future, so SIDs can't be abandoned completely. I also question whether this might be the issue that fully brings the security server layer into question.
