From: Casey Schaufler <email@example.com> To: Paul Moore <firstname.lastname@example.org>, Florian Westphal <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: New skb extension for use by LSMs (skb "security blob")? Date: Thu, 22 Aug 2019 13:10:43 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAHC9VhQ_+3ywPu0QRzP3cSgPH2i9Br994wJttp-yXy2GA4FrNg@mail.gmail.com> On 8/22/2019 9:32 AM, Paul Moore wrote: > On Thu, Aug 22, 2019 at 3:03 AM Florian Westphal <email@example.com> wrote: >> Paul Moore <firstname.lastname@example.org> wrote: >>> Hello netdev, >>> >>> I was just made aware of the skb extension work, and it looks very >>> appealing from a LSM perspective. As some of you probably remember, >>> we (the LSM folks) have wanted a proper security blob in the skb for >>> quite some time, but netdev has been resistant to this idea thus far. >> Is that "blob" in addition to skb->secmark, or a replacement? > That's a good question. While I thought about that, I wasn't sure if > that was worth bringing up as previous attempts to trade the secmark > field for a void pointer met with failure. Last time I played with it > I was able to take the additional 32-bits from holes in the skb, and > possibly even improve some of the cacheline groupings (but that is > always going to be a dependent on use case I think), but that wasn't > enough. > > I think we could consider freeing up the secmark in the main skb, and > move it to a skb extension, but this would potentially increase the > chances that we would need to add an extension to a skb. I don't have > any hard numbers, but based on discussions and questions I suspect > Secmark is more widely used than NetLabel and/or labeled IPsec; > although I'm confident it is still a minor percentage of the overall > Linux installed base. Smack uses both extensively. As far as Smack is concerned giving up the secmark for a blob would be just fine. I am also working on security module stacking, and a blob in the skb would dramatically improve the options for making that work rationally. > For me the big question is what would it take for us to get a security > blob associated with the skb? Would moving the secmark into the skb > extension be enough? Something else? Or is this simply never going > to happen? I want to remain optimistic, but I've been trying for this > off-and-on for over a decade and keep running into a brick wall ;) Given that the original objection to using a skb extension for a security blob was that an extension is dynamic, and that the ubiquitous nature of LSM use makes that unreasonable, it would seem that supporting the security blob as a basic part if the skb would be the obvious and correct solution. If the normal case is that there is an LSM that would befit from the native (unextended) support of a blob, it would seem that that is the case that should be optimized.
next prev parent reply index Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-21 22:00 Paul Moore 2019-08-21 22:50 ` David Miller 2019-08-22 3:27 ` Paul Moore 2019-08-22 3:54 ` David Miller 2019-08-22 18:50 ` Casey Schaufler 2019-08-22 7:03 ` Florian Westphal 2019-08-22 16:32 ` Paul Moore 2019-08-22 20:10 ` Casey Schaufler [this message] 2019-08-22 20:15 ` Florian Westphal 2019-08-22 20:35 ` Casey Schaufler 2019-08-22 21:18 ` David Miller 2019-08-22 21:59 ` Casey Schaufler 2019-08-22 22:28 ` David Miller 2019-08-22 22:34 ` Casey Schaufler 2019-08-22 22:36 ` David Miller 2019-08-23 18:56 ` Casey Schaufler 2019-08-22 21:17 ` David Miller
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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: link
SELinux Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \ firstname.lastname@example.org public-inbox-index selinux Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.selinux AGPL code for this site: git clone https://public-inbox.org/public-inbox.git