From: Paul Moore <paul@paul-moore.com> To: Casey Schaufler <casey@schaufler-ca.com> Cc: James Morris <jmorris@namei.org>, Stephen Smalley <sds@tycho.nsa.gov>, LSM <linux-security-module@vger.kernel.org>, SELinux <selinux@tycho.nsa.gov> Subject: Re: [PATCH 00/23] LSM: Full security module stacking Date: Wed, 16 May 2018 20:19:49 -0400 [thread overview] Message-ID: <CAHC9VhT9JcADHexQq3qkEZ6JfkPwyw8tD3mD6JUFbwKN+w10=A@mail.gmail.com> (raw) In-Reply-To: <77dbe49f-b0fc-5b58-f8c2-a87db6b00ebc@schaufler-ca.com> On Wed, May 16, 2018 at 1:42 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/15/2018 2:49 PM, James Morris wrote: >> On Tue, 15 May 2018, Casey Schaufler wrote: >> >>> Both SELinux and Smack use netlbl_sock_setattr() in their socket_post_create() >>> hooks to establish the CIPSO to use if nothing else interferes. An unfortunate >>> artifact of the Smack "ambient label" implementation is that the default >>> configuration is going to delete the netlbl attribute for the floor ("_") >>> label. This will conflict with any value that SELinux sets. :( Smack clearly >>> needs to have it's use of netlabel revised, and that is work that's going on >>> in parallel with stacking. That, however, is not an infrastructure issue, it's >>> an issue with how the two modules use the facilities. >> Can this kind of problem be prevented at the API level? i.e. ensure you >> can't accidentally conflict with another LSM's use of the label here? > > What we're seeing isn't an accidental conflict. SELinux and Smack > use netlabel differently. SELinux uses netlabel the way it and the > way CIPSO intended, to mark the MLS levels and categories on a > packet. Smack (ab)uses netlabel to put the Smack label directly on > the packet. In most cases a SELinux system won't be sending a CIPSO > header at all, because it won't be using MLS. A Smack system, on > the other hand, sends a CIPSO header unless the label is the > "ambient" label. Further, the label transitions for a process using > both SELinux and Smack will be different. Two system services may > have different SELinux contexts but the same Smack label. Also, to clarify things a bit for those who haven't dug too deeply into the per-packet bits, the label match/conflict is not done using the individual LSM labels, that would be impossible, it is done using the netlbl_lsm_secattr values. The netlbl_lsm_secattr "label" was always intended to be both LSM and protocol agnostic so it lends itself better for this type of comparison. At least that is what Casey and I discussed. I haven't had a chance to look at the most recent patches in-depth. [ASIDE: I was just digging through the patches to look for some of the networking changes and it appears there is confusion around SELinux's use of secmark and the NetLabel/IPsec "peer" labels. As an example, the term "secmark" should never appear in cipso_ipv4.c; the secmark labels are completely independent to the peer labels.] [ASIDE #2: Are you ever comparing the packet labels for domains/sockets which are setup for destination specific labeling (NetLabel's "address selector" feature)? I'm probably missing it, but I don't see it in the patches.] > The Smack code clearly needs to be revised. It does a horrible job > on single-level hosts. It works, but does not take advantage of the > netlabel facilities well. The ambient label processing is pretty > kludgey. If the Smack use of netlabel were more in line with the > SELinux model I expect there would be more cases where they work > together. But even in the best case, it's going to take some real > configuration wizardry to get a lot of agreement on packet labeling. The answer may be to do the label comparison farther down the stack. What does it matter if the LSMs don't agree on their network labels so long as the outgoing packets would be labeled the same? In the default SELinux and Smack configurations both send unlabeled traffic (Smack would be using the ambient label by default, yes?) so if we ask NetLabel to compare the on-wire label vs the LSM label, or the netlbl_lsm_secattr label, it *should* be okay. Incoming packets, even labeled ones, *should* work just fine so long as the NetLabel caching mechanism is avoided (although you *really* want to use the caching mechanism). It should be easy enough to add multiple LSM support to NetLabel's caching mechanism to fix this. We get a pass on labeled IPsec because it is only used by SELinux. Thank goodness. That's a feature that should fade away. > I'm not saying that API level changes wouldn't be welcome. I would > be happier if the networking code called security hooks like the > other subsystems do. I also understand that there are critical > performance issues that drove the existing implementation, and that > a call to security_label_packet() in the IP stack could be a hard > sell. Honestly, after my last round with the netdev folks, the issue isn't so much the hooks themselves, but rather the sk_buff and their insistence on not giving us any more than 32-bits. Even trading 32-bits for 64 was a no-go despite multiple different alignment attempts. It's unfortunate because independent of stacking there are several use cases we handle poorly today because of this (anyone looked at packet forwarding for labeled traffic? have you looked at forwarding labeled traffic across different protocols?). Having thought about this on and off for several years now, I think the only realistic solution may be to repurpose the secmark field as an index into a larger label store where we can store a more traditional security blob (stacked or otherwise). I hold out some hope that we might be able to do something with skb_shared_info; it's common across cloned packets, but I don't think that would be a problem for us. We might even be able to strike a bargain with the netdev folks: "I'll trade you 32-bits in sk_buff for a pointer in skb_shared_info along with the necessary lifecycle hooks." ... fair warning, that last bit is speculation on my part; I'm guessing they are slightly (so very slightly) less picky about skb_shared_info but there is a good chance I'm wrong about that. -- paul moore www.paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: paul@paul-moore.com (Paul Moore) To: linux-security-module@vger.kernel.org Subject: [PATCH 00/23] LSM: Full security module stacking Date: Wed, 16 May 2018 20:19:49 -0400 [thread overview] Message-ID: <CAHC9VhT9JcADHexQq3qkEZ6JfkPwyw8tD3mD6JUFbwKN+w10=A@mail.gmail.com> (raw) In-Reply-To: <77dbe49f-b0fc-5b58-f8c2-a87db6b00ebc@schaufler-ca.com> On Wed, May 16, 2018 at 1:42 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/15/2018 2:49 PM, James Morris wrote: >> On Tue, 15 May 2018, Casey Schaufler wrote: >> >>> Both SELinux and Smack use netlbl_sock_setattr() in their socket_post_create() >>> hooks to establish the CIPSO to use if nothing else interferes. An unfortunate >>> artifact of the Smack "ambient label" implementation is that the default >>> configuration is going to delete the netlbl attribute for the floor ("_") >>> label. This will conflict with any value that SELinux sets. :( Smack clearly >>> needs to have it's use of netlabel revised, and that is work that's going on >>> in parallel with stacking. That, however, is not an infrastructure issue, it's >>> an issue with how the two modules use the facilities. >> Can this kind of problem be prevented at the API level? i.e. ensure you >> can't accidentally conflict with another LSM's use of the label here? > > What we're seeing isn't an accidental conflict. SELinux and Smack > use netlabel differently. SELinux uses netlabel the way it and the > way CIPSO intended, to mark the MLS levels and categories on a > packet. Smack (ab)uses netlabel to put the Smack label directly on > the packet. In most cases a SELinux system won't be sending a CIPSO > header at all, because it won't be using MLS. A Smack system, on > the other hand, sends a CIPSO header unless the label is the > "ambient" label. Further, the label transitions for a process using > both SELinux and Smack will be different. Two system services may > have different SELinux contexts but the same Smack label. Also, to clarify things a bit for those who haven't dug too deeply into the per-packet bits, the label match/conflict is not done using the individual LSM labels, that would be impossible, it is done using the netlbl_lsm_secattr values. The netlbl_lsm_secattr "label" was always intended to be both LSM and protocol agnostic so it lends itself better for this type of comparison. At least that is what Casey and I discussed. I haven't had a chance to look at the most recent patches in-depth. [ASIDE: I was just digging through the patches to look for some of the networking changes and it appears there is confusion around SELinux's use of secmark and the NetLabel/IPsec "peer" labels. As an example, the term "secmark" should never appear in cipso_ipv4.c; the secmark labels are completely independent to the peer labels.] [ASIDE #2: Are you ever comparing the packet labels for domains/sockets which are setup for destination specific labeling (NetLabel's "address selector" feature)? I'm probably missing it, but I don't see it in the patches.] > The Smack code clearly needs to be revised. It does a horrible job > on single-level hosts. It works, but does not take advantage of the > netlabel facilities well. The ambient label processing is pretty > kludgey. If the Smack use of netlabel were more in line with the > SELinux model I expect there would be more cases where they work > together. But even in the best case, it's going to take some real > configuration wizardry to get a lot of agreement on packet labeling. The answer may be to do the label comparison farther down the stack. What does it matter if the LSMs don't agree on their network labels so long as the outgoing packets would be labeled the same? In the default SELinux and Smack configurations both send unlabeled traffic (Smack would be using the ambient label by default, yes?) so if we ask NetLabel to compare the on-wire label vs the LSM label, or the netlbl_lsm_secattr label, it *should* be okay. Incoming packets, even labeled ones, *should* work just fine so long as the NetLabel caching mechanism is avoided (although you *really* want to use the caching mechanism). It should be easy enough to add multiple LSM support to NetLabel's caching mechanism to fix this. We get a pass on labeled IPsec because it is only used by SELinux. Thank goodness. That's a feature that should fade away. > I'm not saying that API level changes wouldn't be welcome. I would > be happier if the networking code called security hooks like the > other subsystems do. I also understand that there are critical > performance issues that drove the existing implementation, and that > a call to security_label_packet() in the IP stack could be a hard > sell. Honestly, after my last round with the netdev folks, the issue isn't so much the hooks themselves, but rather the sk_buff and their insistence on not giving us any more than 32-bits. Even trading 32-bits for 64 was a no-go despite multiple different alignment attempts. It's unfortunate because independent of stacking there are several use cases we handle poorly today because of this (anyone looked at packet forwarding for labeled traffic? have you looked at forwarding labeled traffic across different protocols?). Having thought about this on and off for several years now, I think the only realistic solution may be to repurpose the secmark field as an index into a larger label store where we can store a more traditional security blob (stacked or otherwise). I hold out some hope that we might be able to do something with skb_shared_info; it's common across cloned packets, but I don't think that would be a problem for us. We might even be able to strike a bargain with the netdev folks: "I'll trade you 32-bits in sk_buff for a pointer in skb_shared_info along with the necessary lifecycle hooks." ... fair warning, that last bit is speculation on my part; I'm guessing they are slightly (so very slightly) less picky about skb_shared_info but there is a good chance I'm wrong about that. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-17 0:20 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-11 0:30 [PATCH 00/23] LSM: Full security module stacking Casey Schaufler 2018-05-11 0:30 ` Casey Schaufler 2018-05-11 0:30 ` Casey Schaufler 2018-05-11 0:52 ` [PATCH 01/23] procfs: add smack subdir to attrs Casey Schaufler 2018-05-11 0:52 ` Casey Schaufler 2018-05-11 0:52 ` [PATCH 02/23] Smack: Abstract use of cred security blob Casey Schaufler 2018-05-11 0:52 ` Casey Schaufler 2018-05-11 0:52 ` [PATCH 03/23] SELinux: " Casey Schaufler 2018-05-11 0:52 ` Casey Schaufler 2018-05-11 0:52 ` [PATCH 04/23] LSM: Infrastructure management of the cred security Casey Schaufler 2018-05-11 0:52 ` Casey Schaufler 2018-05-11 0:52 ` [PATCH 05/23] SELinux: Abstract use of file security blob Casey Schaufler 2018-05-11 0:52 ` Casey Schaufler 2018-05-11 0:53 ` [PATCH 06/23] LSM: Infrastructure management of the file security Casey Schaufler 2018-05-11 0:53 ` Casey Schaufler 2018-05-11 0:53 ` [PATCH 07/23] LSM: Infrastructure management of the task security Casey Schaufler 2018-05-11 0:53 ` Casey Schaufler 2018-05-11 0:53 ` [PATCH 08/23] SELinux: Abstract use of inode security blob Casey Schaufler 2018-05-11 0:53 ` Casey Schaufler 2018-05-11 0:53 ` [PATCH 09/23] Smack: " Casey Schaufler 2018-05-11 0:53 ` Casey Schaufler 2018-05-11 0:53 ` [PATCH 10/23] LSM: Infrastructure management of the inode security Casey Schaufler 2018-05-11 0:53 ` Casey Schaufler 2018-05-14 15:04 ` Stephen Smalley 2018-05-14 15:04 ` Stephen Smalley 2018-05-14 16:32 ` Casey Schaufler 2018-05-14 16:32 ` Casey Schaufler 2018-05-11 0:54 ` [PATCH 11/23] LSM: Infrastructure management of the superblock Casey Schaufler 2018-05-11 0:54 ` Casey Schaufler 2018-05-11 0:54 ` [PATCH 12/23] LSM: Infrastructure management of the sock security Casey Schaufler 2018-05-11 0:54 ` Casey Schaufler 2018-05-11 0:54 ` [PATCH 13/23] LSM: Infrastructure management of the ipc security blob Casey Schaufler 2018-05-11 0:54 ` Casey Schaufler 2018-05-11 0:54 ` [PATCH 14/23] LSM: Infrastructure management of the key " Casey Schaufler 2018-05-11 0:54 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 15/23] LSM: Mark security blob allocation failures as unlikely Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 16/23] LSM: Sharing of security blobs Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 17/23] LSM: Allow mount options from multiple security modules Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 18/23] LSM: Use multiple secids in security module interfaces Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 19/23] LSM: Use multiple secids in LSM interfaces Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-11 0:55 ` [PATCH 20/23] LSM: Move common usercopy into Casey Schaufler 2018-05-11 0:55 ` Casey Schaufler 2018-05-14 15:12 ` Stephen Smalley 2018-05-14 15:12 ` Stephen Smalley 2018-05-14 16:53 ` Stephen Smalley 2018-05-14 16:53 ` Stephen Smalley 2018-05-14 18:55 ` Casey Schaufler 2018-05-14 18:55 ` Casey Schaufler 2018-05-11 0:56 ` [PATCH 21/23] LSM: Multiple concurrent major security modules Casey Schaufler 2018-05-11 0:56 ` Casey Schaufler 2018-05-28 11:42 ` [lkp-robot] [LSM] acde387a6d: vm-scalability.throughput -58.0% regression kernel test robot 2018-05-11 0:56 ` [PATCH 22/23] LSM: Fix setting of the IMA data in inode init Casey Schaufler 2018-05-11 0:56 ` Casey Schaufler 2018-05-11 0:56 ` [PATCH 23/23] Netfilter: Add a selection for Smack Casey Schaufler 2018-05-11 0:56 ` Casey Schaufler 2018-05-11 0:58 ` [PATCH 00/23] LSM: Full security module stacking Casey Schaufler 2018-05-11 0:58 ` Casey Schaufler 2018-05-11 20:25 ` [PATCH 24/23] LSM: Functions for dealing with struct secids Casey Schaufler 2018-05-11 20:25 ` Casey Schaufler [not found] ` <523afc0b-5bfc-8b95-05ee-450679254a47@tycho.nsa.gov> [not found] ` <5716ab22-4d3c-1935-41f1-ba848570ccab@tycho.nsa.gov> [not found] ` <eab001ca-10ff-1cfe-9436-805840628784@schaufler-ca.com> 2018-05-15 12:33 ` [PATCH 00/23] LSM: Full security module stacking Stephen Smalley 2018-05-15 12:33 ` Stephen Smalley 2018-05-15 15:47 ` Casey Schaufler 2018-05-15 15:47 ` Casey Schaufler 2018-05-15 21:49 ` James Morris 2018-05-15 21:49 ` James Morris 2018-05-16 17:42 ` Casey Schaufler 2018-05-16 17:42 ` Casey Schaufler 2018-05-17 0:19 ` Paul Moore [this message] 2018-05-17 0:19 ` Paul Moore 2018-05-17 1:05 ` Casey Schaufler 2018-05-17 1:05 ` Casey Schaufler 2018-05-18 0:28 ` Paul Moore 2018-05-18 0:28 ` Paul Moore
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHC9VhT9JcADHexQq3qkEZ6JfkPwyw8tD3mD6JUFbwKN+w10=A@mail.gmail.com' \ --to=paul@paul-moore.com \ --cc=casey@schaufler-ca.com \ --cc=jmorris@namei.org \ --cc=linux-security-module@vger.kernel.org \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.