On Fri, Aug 16, 2024 at 11:02 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > 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. For those following along, I have pushed a commit that introduces a global SID table [1]. It does not yet change any code to start using this global SID table, so that's next. Rather than introduce yet another data structure, I reused the existing SID table structures and code. For the global SID table, we only use the SID and the context str, len fields for all entries. If we later decide to optimize the global SID table more specifically, that can be done easily enough. [1] https://github.com/stephensmalley/selinux-kernel/commit/9a36707bbf26aeaac39fed27cd0419949241317d
