From: John Johansen <john.johansen@canonical.com> To: Casey Schaufler <casey@schaufler-ca.com>, Paul Moore <paul@paul-moore.com> Cc: LSM List <linux-security-module@vger.kernel.org>, James Morris <jmorris@namei.org>, linux-audit@redhat.com, Mimi Zohar <zohar@linux.ibm.com>, keescook@chromium.org, SElinux list <selinux@vger.kernel.org> Subject: Re: LSM stacking in next for 6.1? Date: Wed, 7 Sep 2022 17:19:27 -0700 [thread overview] Message-ID: <8a013c40-83af-9347-c395-6a95a3c091ed@canonical.com> (raw) In-Reply-To: <6552af17-e511-a7d8-f462-cafcf41a33bb@schaufler-ca.com> On 9/7/22 16:53, Casey Schaufler wrote: > On 9/7/2022 4:27 PM, Paul Moore wrote: >> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>> On 9/7/2022 7:41 AM, Paul Moore wrote: >>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen >>>> <john.johansen@canonical.com> wrote: >>>>> On 9/6/22 16:24, Paul Moore wrote: >>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote: >>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> .. >>>> >>>>>> If you are running AppArmor on the host system and SELinux in a >>>>>> container you are likely going to have some *very* bizarre behavior as >>>>>> the SELinux policy you load in the container will apply to the entire >>>>>> system, including processes which started *before* the SELinux policy >>>>>> was loaded. While I understand the point you are trying to make, I >>>>>> don't believe the example you chose is going to work without a lot of >>>>>> other changes. >>>>> correct but the reverse does work ... >>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up. >>> I said that I'm not sure how they go about doing Android on Ubuntu. >>> I brought it up because I've seen it. >> Addressed in the other portion of this thread, but the quick response >> here is: No, you were mistaken, that was not proper Android, SELinux >> was disabled. >> >>>> I'm sympathetic that this >>>> work has been going on for some time, but that is no reason to push >>>> through a bad design; look at the ACKs/reviews on the combined-label >>>> patches vs the others in the series, that's a pretty good indication >>>> that no one is really excited about that design. >>> The kernel developers aren't the consumers of these APIs. There >>> has been considerable feedback from system application developers >>> on the interfaces. This included dbus and systemd. Kernel developers >>> aren't interested in these APIs because they don't care one way or >>> the other. That, and as you are painfully aware, some of them are >>> really busy on their own projects. >> Yes, everyone is busy yet they found time to ACK/review the other >> patches in the patchset. I'm not buying the "busy" argument here. >> >> Yes, you are also correct in that the kernel devs are not likely to be >> the main consumers of any kernel/userspace API, but we do have to >> support these APIs and find ways to handle the inevitable misuse and >> abuse of these APIs. Further, while I do believe that you've talked >> to some application developers about the current proposed API, I'm >> reasonably confident that it isn't the only API they would be happy >> supporting in their applications. >> >> As far as kernel developers not being interested in these APIs, I >> think the recent conversation in this thread proves the exact opposite >> ;) >> >>> Am I really happy with the "hideous" format? Yeah, because it makes >>> the end user happy. Am I happy with interface_lsm? Other than the >>> name, which was the result of feedback, yes, because it in the >>> simplest way to accomplish the goal. >>> >>> I am curious about what you think is "bad" about the current design. >>> The interfaces aren't exciting. They don't need to be. >> I don't even know what an exciting interface would look like ... ? > > io_uring? :) > >> I >> just want an interface that is clearly defined, has reasonable >> capacity to be extended in the future as needed, and is easy(ish) to >> use and support over extended periods of time (both from a kernel and >> userspace perspective). >> >> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0" >> string interface is none of these things. > > In this we disagree .... > >> It is not clearly defined >> as it requires other interfaces to associate the labels with the >> correct LSMs. > > The label follows the lsm name directly. What other association is required? > its a serialized message format, with all the data in the message instead of pointer to external memory. If you want nicer to handle you wrap a lib around it, this is pretty common. That is why I don't see it as that different from the syscall. >> It has no provision for extension beyond adding a new >> LSM. > > I grant that. But the purpose of the format is to present LSM/context > pairs. What other information would make sense? We could add an "aux" > field, but that seems somewhat arbitrary. > or you know a header that gives potential future, also potentially a count, ... >> The ease-of-use quality is a bit subjective, but it does need >> another interface to use properly and it requires string parsing which >> history has shown to be an issue time and time again (although it is >> relatively simple here). > > There was a lot of discussion regarding that. My proposed > apparmor="unconfined",smack="User" format was panned for those same reasons. > The nil byte format has been used elsewhere and suggested for that reason. > At this level the lib provides the ease of use, but I think that is what we are going to need with a syscall too, as marshalling variable number/length data is always somewhat ugly. >> >> Once again, the syscall example I tossed out was a quick strawman, but >> it had clearly separated and defined labels conveyed in data >> structures that didn't require string parsing to find the label >> associated with an LSM. > > True, but it uses pointers internally and you can't do that in memory > you're sending up from the system. What comes from the syscall has to Well you can, see the mess that is ioctl. The point being those internal pointers are going to have to be mapped/copied and doing that is a mess as well. Either way you want a common set of code to handle it. The advantage of the syscall, from a userspace perspective, is that all the code to handle the mapping is in the kernel. The problem from kernel perspective is that multiple copies to/from userspace have races. You have to make sure you have marshalled/setup all the data before you can do anything with it. > look something like the nil byte format. The strawman would have to do > the same sort of parsing in userspace that you are objecting to. > Not necessarily the nil byte format, but yeah it all has to be setup nicely in advance. >> It was also self-contained in that no other >> interface was needed to interpret the results of the syscall (well, >> beyond the header file definitions I guess). Finally, it made use of >> flags and "reserved for future use" token values to allow for >> additional data to be conveyed in the future. > > Can you describe potential flags or additional data? Planning for the future > is a good idea, but throwing fields on "just in case" seems contrary to > what I'm used to hearing from you. > Well a few potential ones I can think of version - providing future flexibility count - for how many lsm entries to expect size - I don't think its really necessary here but in a message format it is usually good to have a size of message value. kind - some flags indicating the type of data. Eg. LSM name, LSM context pair table - not necessary unless we want to get rid of the \0 separator so that \0 could be allowed as value within the data, an index into the message for each LSMs data. At this point I don't really care if its a syscall or a serialized message. I see them as roughly equivalent, its just a matter of where you are going to put the ugly.
WARNING: multiple messages have this Message-ID (diff)
From: John Johansen <john.johansen@canonical.com> To: Casey Schaufler <casey@schaufler-ca.com>, Paul Moore <paul@paul-moore.com> Cc: SElinux list <selinux@vger.kernel.org>, James Morris <jmorris@namei.org>, Mimi Zohar <zohar@linux.ibm.com>, LSM List <linux-security-module@vger.kernel.org>, linux-audit@redhat.com Subject: Re: LSM stacking in next for 6.1? Date: Wed, 7 Sep 2022 17:19:27 -0700 [thread overview] Message-ID: <8a013c40-83af-9347-c395-6a95a3c091ed@canonical.com> (raw) In-Reply-To: <6552af17-e511-a7d8-f462-cafcf41a33bb@schaufler-ca.com> On 9/7/22 16:53, Casey Schaufler wrote: > On 9/7/2022 4:27 PM, Paul Moore wrote: >> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>> On 9/7/2022 7:41 AM, Paul Moore wrote: >>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen >>>> <john.johansen@canonical.com> wrote: >>>>> On 9/6/22 16:24, Paul Moore wrote: >>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote: >>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> .. >>>> >>>>>> If you are running AppArmor on the host system and SELinux in a >>>>>> container you are likely going to have some *very* bizarre behavior as >>>>>> the SELinux policy you load in the container will apply to the entire >>>>>> system, including processes which started *before* the SELinux policy >>>>>> was loaded. While I understand the point you are trying to make, I >>>>>> don't believe the example you chose is going to work without a lot of >>>>>> other changes. >>>>> correct but the reverse does work ... >>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up. >>> I said that I'm not sure how they go about doing Android on Ubuntu. >>> I brought it up because I've seen it. >> Addressed in the other portion of this thread, but the quick response >> here is: No, you were mistaken, that was not proper Android, SELinux >> was disabled. >> >>>> I'm sympathetic that this >>>> work has been going on for some time, but that is no reason to push >>>> through a bad design; look at the ACKs/reviews on the combined-label >>>> patches vs the others in the series, that's a pretty good indication >>>> that no one is really excited about that design. >>> The kernel developers aren't the consumers of these APIs. There >>> has been considerable feedback from system application developers >>> on the interfaces. This included dbus and systemd. Kernel developers >>> aren't interested in these APIs because they don't care one way or >>> the other. That, and as you are painfully aware, some of them are >>> really busy on their own projects. >> Yes, everyone is busy yet they found time to ACK/review the other >> patches in the patchset. I'm not buying the "busy" argument here. >> >> Yes, you are also correct in that the kernel devs are not likely to be >> the main consumers of any kernel/userspace API, but we do have to >> support these APIs and find ways to handle the inevitable misuse and >> abuse of these APIs. Further, while I do believe that you've talked >> to some application developers about the current proposed API, I'm >> reasonably confident that it isn't the only API they would be happy >> supporting in their applications. >> >> As far as kernel developers not being interested in these APIs, I >> think the recent conversation in this thread proves the exact opposite >> ;) >> >>> Am I really happy with the "hideous" format? Yeah, because it makes >>> the end user happy. Am I happy with interface_lsm? Other than the >>> name, which was the result of feedback, yes, because it in the >>> simplest way to accomplish the goal. >>> >>> I am curious about what you think is "bad" about the current design. >>> The interfaces aren't exciting. They don't need to be. >> I don't even know what an exciting interface would look like ... ? > > io_uring? :) > >> I >> just want an interface that is clearly defined, has reasonable >> capacity to be extended in the future as needed, and is easy(ish) to >> use and support over extended periods of time (both from a kernel and >> userspace perspective). >> >> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0" >> string interface is none of these things. > > In this we disagree .... > >> It is not clearly defined >> as it requires other interfaces to associate the labels with the >> correct LSMs. > > The label follows the lsm name directly. What other association is required? > its a serialized message format, with all the data in the message instead of pointer to external memory. If you want nicer to handle you wrap a lib around it, this is pretty common. That is why I don't see it as that different from the syscall. >> It has no provision for extension beyond adding a new >> LSM. > > I grant that. But the purpose of the format is to present LSM/context > pairs. What other information would make sense? We could add an "aux" > field, but that seems somewhat arbitrary. > or you know a header that gives potential future, also potentially a count, ... >> The ease-of-use quality is a bit subjective, but it does need >> another interface to use properly and it requires string parsing which >> history has shown to be an issue time and time again (although it is >> relatively simple here). > > There was a lot of discussion regarding that. My proposed > apparmor="unconfined",smack="User" format was panned for those same reasons. > The nil byte format has been used elsewhere and suggested for that reason. > At this level the lib provides the ease of use, but I think that is what we are going to need with a syscall too, as marshalling variable number/length data is always somewhat ugly. >> >> Once again, the syscall example I tossed out was a quick strawman, but >> it had clearly separated and defined labels conveyed in data >> structures that didn't require string parsing to find the label >> associated with an LSM. > > True, but it uses pointers internally and you can't do that in memory > you're sending up from the system. What comes from the syscall has to Well you can, see the mess that is ioctl. The point being those internal pointers are going to have to be mapped/copied and doing that is a mess as well. Either way you want a common set of code to handle it. The advantage of the syscall, from a userspace perspective, is that all the code to handle the mapping is in the kernel. The problem from kernel perspective is that multiple copies to/from userspace have races. You have to make sure you have marshalled/setup all the data before you can do anything with it. > look something like the nil byte format. The strawman would have to do > the same sort of parsing in userspace that you are objecting to. > Not necessarily the nil byte format, but yeah it all has to be setup nicely in advance. >> It was also self-contained in that no other >> interface was needed to interpret the results of the syscall (well, >> beyond the header file definitions I guess). Finally, it made use of >> flags and "reserved for future use" token values to allow for >> additional data to be conveyed in the future. > > Can you describe potential flags or additional data? Planning for the future > is a good idea, but throwing fields on "just in case" seems contrary to > what I'm used to hearing from you. > Well a few potential ones I can think of version - providing future flexibility count - for how many lsm entries to expect size - I don't think its really necessary here but in a message format it is usually good to have a size of message value. kind - some flags indicating the type of data. Eg. LSM name, LSM context pair table - not necessary unless we want to get rid of the \0 separator so that \0 could be allowed as value within the data, an index into the message for each LSMs data. At this point I don't really care if its a syscall or a serialized message. I see them as roughly equivalent, its just a matter of where you are going to put the ugly. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2022-09-08 0:19 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <791e13b5-bebd-12fc-53de-e9a86df23836.ref@schaufler-ca.com> 2022-08-03 0:01 ` LSM stacking in next for 6.1? Casey Schaufler 2022-08-03 0:01 ` Casey Schaufler 2022-08-03 0:56 ` Paul Moore 2022-08-03 0:56 ` Paul Moore 2022-08-03 1:56 ` John Johansen 2022-08-03 1:56 ` John Johansen 2022-08-03 2:15 ` Casey Schaufler 2022-08-03 2:15 ` Casey Schaufler 2022-08-03 2:33 ` Paul Moore 2022-08-03 2:33 ` Paul Moore 2022-08-03 2:34 ` Steve Grubb 2022-08-03 2:34 ` Steve Grubb 2022-08-03 2:40 ` Paul Moore 2022-08-03 2:40 ` Paul Moore 2022-09-02 21:30 ` Paul Moore 2022-09-02 21:30 ` Paul Moore 2022-09-02 23:14 ` Casey Schaufler 2022-09-02 23:14 ` Casey Schaufler 2022-09-02 23:57 ` Casey Schaufler 2022-09-02 23:57 ` Casey Schaufler 2022-09-06 23:24 ` Paul Moore 2022-09-06 23:24 ` Paul Moore 2022-09-07 0:10 ` John Johansen 2022-09-07 0:10 ` John Johansen 2022-09-07 0:39 ` Casey Schaufler 2022-09-07 0:39 ` Casey Schaufler 2022-09-07 0:50 ` John Johansen 2022-09-07 0:50 ` John Johansen 2022-09-07 14:41 ` Paul Moore 2022-09-07 14:41 ` Paul Moore 2022-09-07 16:41 ` Casey Schaufler 2022-09-07 16:41 ` Casey Schaufler 2022-09-07 17:23 ` John Johansen 2022-09-07 17:23 ` John Johansen 2022-09-07 22:57 ` Paul Moore 2022-09-07 22:57 ` Paul Moore 2022-09-07 23:27 ` Paul Moore 2022-09-07 23:27 ` Paul Moore 2022-09-07 23:53 ` Casey Schaufler 2022-09-07 23:53 ` Casey Schaufler 2022-09-08 0:19 ` John Johansen [this message] 2022-09-08 0:19 ` John Johansen 2022-09-08 3:57 ` Paul Moore 2022-09-08 3:57 ` Paul Moore 2022-09-08 18:05 ` Casey Schaufler 2022-09-08 18:05 ` Casey Schaufler 2022-09-08 18:35 ` John Johansen 2022-09-08 18:35 ` John Johansen 2022-09-08 19:32 ` Paul Moore 2022-09-08 19:32 ` Paul Moore 2022-09-08 22:56 ` Casey Schaufler 2022-09-08 22:56 ` Casey Schaufler 2022-09-10 4:17 ` Tetsuo Handa 2022-09-10 4:17 ` Tetsuo Handa 2022-09-12 17:37 ` Casey Schaufler 2022-09-12 17:37 ` Casey Schaufler 2022-09-13 10:47 ` Tetsuo Handa 2022-09-13 10:47 ` Tetsuo Handa 2022-09-13 14:45 ` Casey Schaufler 2022-09-13 14:45 ` Casey Schaufler 2022-09-14 13:57 ` Tetsuo Handa 2022-09-14 13:57 ` Tetsuo Handa 2022-09-14 15:50 ` Casey Schaufler 2022-09-14 15:50 ` Casey Schaufler 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:54 ` John Johansen 2022-09-15 14:54 ` John Johansen 2022-09-15 7:45 ` John Johansen 2022-09-15 7:45 ` John Johansen 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-10-25 9:48 ` Tetsuo Handa 2022-10-25 9:48 ` Tetsuo Handa 2022-10-25 10:26 ` John Johansen 2022-10-25 10:26 ` John Johansen 2022-10-25 11:20 ` Tetsuo Handa 2022-10-25 11:20 ` Tetsuo Handa 2022-10-25 14:12 ` Casey Schaufler 2022-10-25 14:12 ` Casey Schaufler 2022-10-25 22:12 ` Tetsuo Handa 2022-10-25 22:12 ` Tetsuo Handa 2022-10-25 22:41 ` Casey Schaufler 2022-10-25 22:41 ` Casey Schaufler 2022-10-26 10:19 ` Tetsuo Handa 2022-10-26 10:19 ` Tetsuo Handa 2022-10-26 15:30 ` Casey Schaufler 2022-10-26 15:30 ` Casey Schaufler 2022-10-28 10:14 ` John Johansen 2022-10-28 10:14 ` John Johansen 2022-10-30 4:03 ` Tetsuo Handa 2022-10-30 4:03 ` Tetsuo Handa 2022-10-30 7:23 ` John Johansen 2022-10-30 7:23 ` John Johansen 2022-10-30 14:02 ` Tetsuo Handa 2022-10-30 14:02 ` Tetsuo Handa 2022-10-30 16:37 ` Kees Cook 2022-10-30 16:37 ` Kees Cook 2022-10-30 20:56 ` Casey Schaufler 2022-10-30 20:56 ` Casey Schaufler 2022-10-31 10:26 ` Tetsuo Handa 2022-10-31 10:26 ` Tetsuo Handa 2022-10-31 15:47 ` Casey Schaufler 2022-10-31 15:47 ` Casey Schaufler 2022-10-26 20:11 ` Paul Moore 2022-10-26 20:11 ` Paul Moore 2022-10-27 0:02 ` Tetsuo Handa 2022-10-27 0:02 ` Tetsuo Handa 2022-10-28 9:50 ` Paul Moore 2022-10-28 9:50 ` Paul Moore 2022-10-28 13:58 ` Tetsuo Handa 2022-10-28 13:58 ` Tetsuo Handa 2022-10-28 17:40 ` Kees Cook 2022-10-28 17:40 ` Kees Cook 2022-10-29 9:33 ` Tetsuo Handa 2022-10-29 9:33 ` Tetsuo Handa 2022-09-14 13:42 ` Paul Moore 2022-09-14 13:42 ` Paul Moore 2022-09-27 20:54 ` Casey Schaufler 2022-09-27 20:54 ` Casey Schaufler 2022-09-27 22:37 ` Paul Moore 2022-09-27 22:37 ` Paul Moore 2022-09-07 0:31 ` Casey Schaufler 2022-09-07 0:31 ` Casey Schaufler 2022-09-07 15:13 ` Paul Moore 2022-09-07 15:13 ` Paul Moore 2022-09-07 17:08 ` Casey Schaufler 2022-09-07 17:08 ` Casey Schaufler 2022-09-07 23:04 ` Paul Moore 2022-09-07 23:04 ` Paul Moore 2022-09-07 23:26 ` Casey Schaufler 2022-09-07 23:26 ` Casey Schaufler 2022-09-08 15:18 ` Tetsuo Handa 2022-09-08 15:18 ` Tetsuo Handa 2022-09-08 16:00 ` Casey Schaufler 2022-09-08 16:00 ` Casey Schaufler 2022-09-08 18:52 ` Paul Moore 2022-09-08 18:52 ` Paul Moore 2022-09-09 11:32 ` Tetsuo Handa 2022-09-09 11:32 ` Tetsuo Handa 2022-09-14 13:56 ` Paul Moore 2022-09-14 13:56 ` Paul Moore 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 15:50 ` Casey Schaufler 2022-09-15 15:50 ` Casey Schaufler 2022-09-16 13:34 ` Tetsuo Handa 2022-09-16 13:34 ` Tetsuo Handa
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=8a013c40-83af-9347-c395-6a95a3c091ed@canonical.com \ --to=john.johansen@canonical.com \ --cc=casey@schaufler-ca.com \ --cc=jmorris@namei.org \ --cc=keescook@chromium.org \ --cc=linux-audit@redhat.com \ --cc=linux-security-module@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=selinux@vger.kernel.org \ --cc=zohar@linux.ibm.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: 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.