Which of these options would be preferred for audit records when there are multiple active security modules?

I'm not asking if we should do it, I'm asking which of these options I should implement when I do do it. I've prototyped #1 and #2. #4 is a minor variant of #1 that is either better for compatibility or worse, depending on how you want to look at it. I understand that each of these offer challenges. If I've missed something obvious, I'd be delighted to consider #5. Thank you. Option 1: subj=selinux='x:y:z:s:c',apparmor='a' Option 2: subj=x:y:z:s:c subj=a Option 3: lsms=selinux,apparmor subj=x:y:z:s:c subj=a Option 4: subjs=selinux='x:y:z:s:c',apparmor='a' Option 5: Something else.

On 2019-07-13 11:08, Steve Grubb wrote: > Hello, > > On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote: >> Which of these options would be preferred for audit records >> when there are multiple active security modules? > I'd like to start out with what is the underlying problem that results in > this? For example, we have pam. It has multiple modules each having a vote. > If a module votes no, then we need to know who voted no and maybe why. We > normally do not need to know who voted yes. > > So, in a stacked situation, shouldn't each module make its own event, if > required, just like pam? And then log the attributes as it knows them? Also, > what model is being used? Does first module voting no end access voting? Or > does each module get a vote even if one has already said no? > > Also, we try to keep LSM subsystems separated by record type numbers. So, > apparmour and selinux events are entirely different record numbers and > formats. Combining everything into one record is going to be problematic for > reporting. I was wrestling with the options below and was uncomfortable with all of them because none of them was guaranteed not to break existing parsers.

Steve's answer is the obvious one, ideally allocating a seperate range to each LSM with each message type having its own well defined format.

> -Steve > >> I'm not asking >> if we should do it, I'm asking which of these options I should >> implement when I do do it. I've prototyped #1 and #2. #4 is a >> minor variant of #1 that is either better for compatibility or >> worse, depending on how you want to look at it. I understand >> that each of these offer challenges. If I've missed something >> obvious, I'd be delighted to consider #5. >> >> Thank you. >> >> Option 1: >> >> subj=selinux='x:y:z:s:c',apparmor='a' >> >> Option 2: >> >> subj=x:y:z:s:c subj=a >> >> Option 3: >> >> lsms=selinux,apparmor subj=x:y:z:s:c subj=a >> >> Option 4: >> >> subjs=selinux='x:y:z:s:c',apparmor='a' >> >> Option 5: >> >> Something else. - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635

On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey(a)schaufler-ca.com&gt;

> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: > > On 2019-07-13 11:08, Steve Grubb wrote: > >> Hello, > >> > >> On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote: > >>> Which of these options would be preferred for audit records > >>> when there are multiple active security modules? > >> > >> I'd like to start out with what is the underlying problem that results > >> in this? For example, we have pam. It has multiple modules each having > >> a vote. If a module votes no, then we need to know who voted no and > >> maybe why. We normally do not need to know who voted yes. > >> > >> So, in a stacked situation, shouldn't each module make its own event, > >> if required, just like pam? And then log the attributes as it knows > >> them? Also, what model is being used? Does first module voting no end > >> access voting? Or does each module get a vote even if one has already > >> said no? > >> > >> Also, we try to keep LSM subsystems separated by record type numbers. > >> So, apparmour and selinux events are entirely different record numbers > >> and formats. Combining everything into one record is going to be > >> problematic for reporting. > > > > I was wrestling with the options below and was uncomfortable with all > > of them because none of them was guaranteed not to break existing > > parsers. > > I too, am uncomfortable regarding record parsing.

If you can find me someone who is happy and comfortable with the current state of the audit record and/or formatting I would love to see them :) > > Steve's answer is the obvious one, ideally allocating a seperate range > > to each LSM with each message type having its own well defined format. > > It doesn't address the issue of success records, or records > generated outside the security modules. Yes, exactly. The individual LSM will presumably will continue to generate their own audit records as they do today and I would imagine that the subject and object fields could remain as they do today for the LSM specific records. The trick is the other records which are not LSM specific but still want to include subject and/or object information. Unfortunately we are stuck with some tough limitations given the current audit record format and Steve's audit userspace tools;

I can toss out some suggestions but it would be nice to hear what Steve's tools would support with respect to LSM subject/object value formats. Steve, are these values interpreted at all by your tools, or are the opaque values?

On 7/15/2019 3:55 PM, Steve Grubb wrote: > On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; > > wrote: >>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>> On 2019-07-13 11:08, Steve Grubb wrote: >>>>> Hello, >>>>> >>>>> On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote: >>>>>> Which of these options would be preferred for audit records >>>>>> when there are multiple active security modules? >>>>> >>>>> I'd like to start out with what is the underlying problem that >>>>> results >>>>> in this? For example, we have pam. It has multiple modules each >>>>> having >>>>> a vote. If a module votes no, then we need to know who voted no and >>>>> maybe why. We normally do not need to know who voted yes. >>>>> >>>>> So, in a stacked situation, shouldn't each module make its own event, >>>>> if required, just like pam? And then log the attributes as it knows >>>>> them? Also, what model is being used? Does first module voting no end >>>>> access voting? Or does each module get a vote even if one has already >>>>> said no? >>>>> >>>>> Also, we try to keep LSM subsystems separated by record type numbers. >>>>> So, apparmour and selinux events are entirely different record >>>>> numbers >>>>> and formats. Combining everything into one record is going to be >>>>> problematic for reporting. >>>> >>>> I was wrestling with the options below and was uncomfortable with all >>>> of them because none of them was guaranteed not to break existing >>>> parsers. >>> >>> I too, am uncomfortable regarding record parsing. > > The record parsing for this is good as long as we are smart about it. We > have to be able to do searches on subject and object labels. By default, > ausearch uses strstr() to find a fragment of a label. That would still > work the same with multiple labels if done right. > >> If you can find me someone who is happy and comfortable with the >> current state of the audit record and/or formatting I would love to >> see them :) >> >>>> Steve's answer is the obvious one, ideally allocating a seperate range >>>> to each LSM with each message type having its own well defined format. >>> >>> It doesn't address the issue of success records, or records >>> generated outside the security modules. >> >> Yes, exactly. The individual LSM will presumably will continue to >> generate their own audit records as they do today and I would imagine >> that the subject and object fields could remain as they do today for >> the LSM specific records. >> >> The trick is the other records which are not LSM specific but still >> want to include subject and/or object information. Unfortunately we >> are stuck with some tough limitations given the current audit record >> format and Steve's audit userspace tools; > > Not really. We just need to approach the problem thinking about how to > make it work based on how things currently work. For example Casey had a > list of possible formats. Like this one: > > Option 3: > lsms=selinux,apparmor subj=x:y:z:s:c subj=a > > I'd suggest something almost like that. The first field could be a map to > decipher the labels. Then we could have a comma separated list of labels. > > lsms=selinux,apparmor subj=x:y:z:s:c,a Unless there's an objection I will use this format with a slight modification. Smack allows commas in labels, so using a bare comma can lead to ambiguity. lsms=smack,apparmor subj="TS/Alpha,Beta","a" It's more code change than some of the other options, but if it has the best chance of working with user space I'm game.

On 7/16/19 11:14 AM, Steve Grubb wrote: > Quoting has a specific meaning in audit fields. So, we really shouldn't > do > that. We can simply pick another field delimiter. I really don't care > which it is as long as its illegal for use in a label. For example, we > use > > #define AUDIT_KEY_SEPARATOR 0x01 > > to separate key fields. We can pick almost anything. (exclamation mark, > semi- colon, hash, plus symbol, tilde, 0x02, whatever) But it will need > to be documented and put into the API so that everyone is aware of the > convention. > > -Steve Also should it not be the "#define AUDIT_INTERP_SEPARATOR 0x1D" for enriched format records?

On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: > On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > > On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: > > > On 2019-07-13 11:08, Steve Grubb wrote:

> > > Steve's answer is the obvious one, ideally allocating a seperate range > > > to each LSM with each message type having its own well defined format. > > > > It doesn't address the issue of success records, or records > > generated outside the security modules. > > Yes, exactly. The individual LSM will presumably will continue to > generate their own audit records as they do today and I would imagine > that the subject and object fields could remain as they do today for > the LSM specific records. > > The trick is the other records which are not LSM specific but still > want to include subject and/or object information. Unfortunately we > are stuck with some tough limitations given the current audit record > format and Steve's audit userspace tools; Not really. We just need to approach the problem thinking about how to make it work based on how things currently work.

For example Casey had a list of possible formats. Like this one: Option 3: lsms=selinux,apparmor subj=x:y:z:s:c subj=a I'd suggest something almost like that. The first field could be a map to decipher the labels. Then we could have a comma separated list of labels. lsms=selinux,apparmor subj=x:y:z:s:c,a

On 7/16/2019 10:12 AM, Paul Moore wrote: > On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >>> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; >> wrote: >>>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>>> On 2019-07-13 11:08, Steve Grubb wrote: > ... > >>>>> Steve's answer is the obvious one, ideally allocating a seperate range >>>>> to each LSM with each message type having its own well defined format. >>>> It doesn't address the issue of success records, or records >>>> generated outside the security modules. >>> Yes, exactly. The individual LSM will presumably will continue to >>> generate their own audit records as they do today and I would imagine >>> that the subject and object fields could remain as they do today for >>> the LSM specific records. >>> >>> The trick is the other records which are not LSM specific but still >>> want to include subject and/or object information. Unfortunately we >>> are stuck with some tough limitations given the current audit record >>> format and Steve's audit userspace tools; >> Not really. We just need to approach the problem thinking about how to make >> it work based on how things currently work. > I suppose it is all somewhat "subjective" - bad joke fully intended :) > - with respect to what one considers good/bad/limiting. My personal > view is that an ideal solution would allow for multiple independent > subj/obj labels without having to multiplex on a single subj/obj > field. My gut feeling is that this would confuse your tools, yes? > >> For example Casey had a list of possible formats. Like this one: >> >> Option 3: >> lsms=selinux,apparmor subj=x:y:z:s:c subj=a >> >> I'd suggest something almost like that. The first field could be a map to >> decipher the labels. Then we could have a comma separated list of labels. >> >> lsms=selinux,apparmor subj=x:y:z:s:c,a > Some quick comments: > > * My usual reminder that new fields for existing audit records must be > added to the end of the record. > > * If we are going to multiplex the labels on a single field (more on > that below) I might suggest using "subj_lsms" instead of "lsms" so we > leave ourself some wiggle room in the future. > > * Multiplexing on a single "subj" field is going to be difficult > because picking the label delimiter is going to be a pain. For > example, in the example above a comma is used, which at the very least > is a valid part of a SELinux label and I suspect for Smack as well > (I'm not sure about the other LSMs). I suspect the only way to parse > out the component labels would be to have knowledge of the LSMs in > use, as well as the policies loaded at the time the audit record was > generated. > > This may be a faulty assumption, but assuming your tools will fall > over if they see multiple "subj" fields, could we do something like > the following (something between option #2 and #3): > > subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux > subj2=<selinux_label> ... If it's not a subj= field why use the indirection? subj_smack=<smack_label> subj_selinux=<selinux_label> would be easier.

On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler <casey(a)schaufler-ca.com&gt;

> On 7/16/2019 10:12 AM, Paul Moore wrote: > > On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > >> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: > >>> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler > >>> <casey(a)schaufler-ca.com&gt; > >> > >> wrote: > >>>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: > >>>>> On 2019-07-13 11:08, Steve Grubb wrote: > > ... > > > >>>>> Steve's answer is the obvious one, ideally allocating a seperate > >>>>> range > >>>>> to each LSM with each message type having its own well defined > >>>>> format. > >>>> > >>>> It doesn't address the issue of success records, or records > >>>> generated outside the security modules. > >>> > >>> Yes, exactly. The individual LSM will presumably will continue to > >>> generate their own audit records as they do today and I would imagine > >>> that the subject and object fields could remain as they do today for > >>> the LSM specific records. > >>> > >>> The trick is the other records which are not LSM specific but still > >>> want to include subject and/or object information. Unfortunately we > >>> are stuck with some tough limitations given the current audit record > >>> format and Steve's audit userspace tools; > >> > >> Not really. We just need to approach the problem thinking about how to > >> make it work based on how things currently work. > > > > I suppose it is all somewhat "subjective" - bad joke fully intended :) > > - with respect to what one considers good/bad/limiting. My personal > > view is that an ideal solution would allow for multiple independent > > subj/obj labels without having to multiplex on a single subj/obj > > field. My gut feeling is that this would confuse your tools, yes? > > > >> For example Casey had a list of possible formats. Like this one: > >> > >> Option 3: > >> lsms=selinux,apparmor subj=x:y:z:s:c subj=a > >> > >> I'd suggest something almost like that. The first field could be a map > >> to > >> decipher the labels. Then we could have a comma separated list of > >> labels. > >> > >> lsms=selinux,apparmor subj=x:y:z:s:c,a > > > > Some quick comments: > > > > * My usual reminder that new fields for existing audit records must be > > added to the end of the record. > > > > * If we are going to multiplex the labels on a single field (more on > > that below) I might suggest using "subj_lsms" instead of "lsms" so we > > leave ourself some wiggle room in the future. > > > > * Multiplexing on a single "subj" field is going to be difficult > > because picking the label delimiter is going to be a pain. For > > example, in the example above a comma is used, which at the very least > > is a valid part of a SELinux label and I suspect for Smack as well > > (I'm not sure about the other LSMs). I suspect the only way to parse > > out the component labels would be to have knowledge of the LSMs in > > use, as well as the policies loaded at the time the audit record was > > generated. > > > > This may be a faulty assumption, but assuming your tools will fall > > over if they see multiple "subj" fields, could we do something like > > > > the following (something between option #2 and #3): > > subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux > > > > subj2=<selinux_label> ... > > If it's not a subj= field why use the indirection? > > subj_smack=<smack_label> subj_selinux=<selinux_label> > > would be easier. Good point, that looks reasonable to me.

On 7/16/2019 11:06 AM, Steve Grubb wrote: > On Tuesday, July 16, 2019 1:43:18 PM EDT Paul Moore wrote: >> On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; > wrote: >>> On 7/16/2019 10:12 AM, Paul Moore wrote: >>>> On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >>>>> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >>>>>> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler >>>>>> <casey(a)schaufler-ca.com&gt; >>>>> wrote: >>>>>>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>>>>>> On 2019-07-13 11:08, Steve Grubb wrote: >>>> ... >>>> >>>>>>>> Steve's answer is the obvious one, ideally allocating a seperate >>>>>>>> range >>>>>>>> to each LSM with each message type having its own well defined >>>>>>>> format. >>>>>>> It doesn't address the issue of success records, or records >>>>>>> generated outside the security modules. >>>>>> Yes, exactly. The individual LSM will presumably will continue to >>>>>> generate their own audit records as they do today and I would imagine >>>>>> that the subject and object fields could remain as they do today for >>>>>> the LSM specific records. >>>>>> >>>>>> The trick is the other records which are not LSM specific but still >>>>>> want to include subject and/or object information. Unfortunately we >>>>>> are stuck with some tough limitations given the current audit record >>>>>> format and Steve's audit userspace tools; >>>>> Not really. We just need to approach the problem thinking about how to >>>>> make it work based on how things currently work. >>>> I suppose it is all somewhat "subjective" - bad joke fully intended :) >>>> - with respect to what one considers good/bad/limiting. My personal >>>> view is that an ideal solution would allow for multiple independent >>>> subj/obj labels without having to multiplex on a single subj/obj >>>> field. My gut feeling is that this would confuse your tools, yes? >>>> >>>>> For example Casey had a list of possible formats. Like this one: >>>>> >>>>> Option 3: >>>>> lsms=selinux,apparmor subj=x:y:z:s:c subj=a >>>>> >>>>> I'd suggest something almost like that. The first field could be a map >>>>> to >>>>> decipher the labels. Then we could have a comma separated list of >>>>> labels. >>>>> >>>>> lsms=selinux,apparmor subj=x:y:z:s:c,a >>>> Some quick comments: >>>> >>>> * My usual reminder that new fields for existing audit records must be >>>> added to the end of the record. >>>> >>>> * If we are going to multiplex the labels on a single field (more on >>>> that below) I might suggest using "subj_lsms" instead of "lsms" so we >>>> leave ourself some wiggle room in the future. >>>> >>>> * Multiplexing on a single "subj" field is going to be difficult >>>> because picking the label delimiter is going to be a pain. For >>>> example, in the example above a comma is used, which at the very least >>>> is a valid part of a SELinux label and I suspect for Smack as well >>>> (I'm not sure about the other LSMs). I suspect the only way to parse >>>> out the component labels would be to have knowledge of the LSMs in >>>> use, as well as the policies loaded at the time the audit record was >>>> generated. >>>> >>>> This may be a faulty assumption, but assuming your tools will fall >>>> over if they see multiple "subj" fields, could we do something like >>>> >>>> the following (something between option #2 and #3): >>>> subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux >>>> >>>> subj2=<selinux_label> ... >>> If it's not a subj= field why use the indirection? >>> >>> subj_smack=<smack_label> subj_selinux=<selinux_label> >>> >>> would be easier. >> >> Good point, that looks reasonable to me. > > But doing something like this will totally break all parsers. To be honest, I > don't know if I'll ever see more than one labeled security system running at > the same time. And this would be a big penalty to pay for the flexibility that > someone, somewhere just might possibly do this. While I have never seen multiple-LSM plans from RedHat/IBM I have seen them from Ubuntu. This isn't hypothetical. I know that it's a hard problem, which is why we need to get it as right as possible.

On Tuesday, July 16, 2019 5:25:21 PM EDT Paul Moore wrote: > On Tue, Jul 16, 2019 at 2:41 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >> On 7/16/2019 11:06 AM, Steve Grubb wrote: >>> On Tuesday, July 16, 2019 1:43:18 PM EDT Paul Moore wrote: >>>> On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler >>>> <casey(a)schaufler-ca.com&gt; >>> wrote: >>>>> On 7/16/2019 10:12 AM, Paul Moore wrote: >>>>>> On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >>>>>>> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >>>>>>>> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler >>>>>>>> <casey(a)schaufler-ca.com&gt; >>>>>>> wrote: >>>>>>>>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>>>>>>>> On 2019-07-13 11:08, Steve Grubb wrote: >>>>>> ... >>>>>> >>>>>>>>>> Steve's answer is the obvious one, ideally allocating a seperate >>>>>>>>>> range >>>>>>>>>> to each LSM with each message type having its own well defined >>>>>>>>>> format. >>>>>>>>> It doesn't address the issue of success records, or records >>>>>>>>> generated outside the security modules. >>>>>>>> Yes, exactly. The individual LSM will presumably will continue to >>>>>>>> generate their own audit records as they do today and I would >>>>>>>> imagine >>>>>>>> that the subject and object fields could remain as they do today >>>>>>>> for >>>>>>>> the LSM specific records. >>>>>>>> >>>>>>>> The trick is the other records which are not LSM specific but >>>>>>>> still >>>>>>>> want to include subject and/or object information. Unfortunately >>>>>>>> we >>>>>>>> are stuck with some tough limitations given the current audit >>>>>>>> record >>>>>>>> format and Steve's audit userspace tools; >>>>>>> Not really. We just need to approach the problem thinking about how >>>>>>> to >>>>>>> make it work based on how things currently work. >>>>>> I suppose it is all somewhat "subjective" - bad joke fully intended >>>>>> :) >>>>>> - with respect to what one considers good/bad/limiting. My personal >>>>>> view is that an ideal solution would allow for multiple independent >>>>>> subj/obj labels without having to multiplex on a single subj/obj >>>>>> field. My gut feeling is that this would confuse your tools, yes? >>>>>> >>>>>>> For example Casey had a list of possible formats. Like this one: >>>>>>> >>>>>>> Option 3: >>>>>>> lsms=selinux,apparmor subj=x:y:z:s:c subj=a >>>>>>> >>>>>>> I'd suggest something almost like that. The first field could be a >>>>>>> map >>>>>>> to >>>>>>> decipher the labels. Then we could have a comma separated list of >>>>>>> labels. >>>>>>> >>>>>>> lsms=selinux,apparmor subj=x:y:z:s:c,a >>>>>> Some quick comments: >>>>>> >>>>>> * My usual reminder that new fields for existing audit records must >>>>>> be >>>>>> added to the end of the record. >>>>>> >>>>>> * If we are going to multiplex the labels on a single field (more on >>>>>> that below) I might suggest using "subj_lsms" instead of "lsms" so >>>>>> we >>>>>> leave ourself some wiggle room in the future. >>>>>> >>>>>> * Multiplexing on a single "subj" field is going to be difficult >>>>>> because picking the label delimiter is going to be a pain. For >>>>>> example, in the example above a comma is used, which at the very >>>>>> least >>>>>> is a valid part of a SELinux label and I suspect for Smack as well >>>>>> (I'm not sure about the other LSMs). I suspect the only way to >>>>>> parse >>>>>> out the component labels would be to have knowledge of the LSMs in >>>>>> use, as well as the policies loaded at the time the audit record was >>>>>> generated. >>>>>> >>>>>> This may be a faulty assumption, but assuming your tools will fall >>>>>> over if they see multiple "subj" fields, could we do something like >>>>>> >>>>>> the following (something between option #2 and #3): >>>>>> subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux >>>>>> >>>>>> subj2=<selinux_label> ... >>>>> If it's not a subj= field why use the indirection? >>>>> >>>>> subj_smack=<smack_label> subj_selinux=<selinux_label> >>>>> >>>>> would be easier. >>>> Good point, that looks reasonable to me. >>> But doing something like this will totally break all parsers. To be >>> honest, I don't know if I'll ever see more than one labeled security >>> system running at the same time. And this would be a big penalty to >>> pay for the flexibility that someone, somewhere just might possibly do >>> this. >> While I have never seen multiple-LSM plans from RedHat/IBM I >> have seen them from Ubuntu. This isn't hypothetical. I know that >> it's a hard problem, which is why we need to get it as right as >> possible. > Agreed. While I'm not going to be on a specific Linux release, I do > believe that at some point in the future the LSM stacking work is > going to land in Linus' tree. Perhaps you'll never see it Steve, but > we need to prepare the code to handle it when it happens. And I agree with that. I'm saying that if we push it all in subj= then it is not a big penalty. It saves major breakage. Every single event is required to have a subj= field if its a MAC system. By changing it to lsm_subj= it changes the layout of every single event. And it make more to parse. And searching the labels is worse because it has to iterate over a list of *_subj to match it. This will hurt performance because it is for every single event. > For my own sanity, here is a quick summary of the constraints as I > currently see them, please feel free to add/disagree: > > * We can't have multiple "subj" fields in a single audit record. > * The different LSMs all have different label formats and allowed > characters. Further, a given label format may not be unique for a > given LSM; for example, Smack could be configured with a subset of > SELinux labels. > * Steve's audit tools appear to require a "subj" and "obj" fields for > LSM information or else they break into tiny little pieces. It changes all knowledge of where to look for things. And considering considering that events could be aggregated from systems of different ages/ distributions, audit userspace will always have to be backwards compatible. > What if we preserved the existing subj/obj fields in the case where > there is only one "major" LSM (SELinux, Smack, AppArmor, etc.): > > subj=<lsm_label> > > ... and in the case of multiple major LSMs we set the subj value to > "?" and introduce new subj_X fields (as necessary) as discussed above: > > subj=? subj_smack=<smack_label> subj_selinux=<selinux_label> ... > > ... I believe that Steve's old/existing userspace tools would simply > report "?"/unknown LSM credentials where new multi-LSM tools could > report the multiple different labels. Common Criteria as well as other standards require subject labels to be searchable. So, changing behavior based on how many modules will still cause problems with performance because I'll always have to assume it could be either way and try both. > While this may not be perfect, > it avoids having to multiplex the different labels into a single field > (which is a big win IMHO) with the only issue being that multi-LSM > solutions will need an updated audit toolset to see the new labels > (which seems like a reasonable requirement). Why would not multiplexing different labels in the same field be a big win? Its a big loss in my mind. Using the same field preserves backward compatibility, is more compact in bytes, creates performance problems, changes all mapping of what things means, etc. IOW, this makes things much worse.

-Steve

On Tue, Jul 16, 2019 at 6:18 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > It sounds as if some variant of the Hideous format: > > subj=selinux='a:b:c:d',apparmor='z' > subj=selinux/a:b:c:d/apparmor/z > subj=(selinux)a:b:c:d/(apparmor)z > > would meet Steve's searchability requirements, but with significant > parsing performance penalties. I think "hideous format" sums it up nicely. Whatever we choose here we are likely going to be stuck with for some time and I'm near to 100% that multiplexing the labels onto a single field is going to be a disaster.

On Tue, Jul 16, 2019 at 7:47 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 7/16/2019 4:13 PM, Paul Moore wrote: >> On Tue, Jul 16, 2019 at 6:18 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>> It sounds as if some variant of the Hideous format: >>> >>> subj=selinux='a:b:c:d',apparmor='z' >>> subj=selinux/a:b:c:d/apparmor/z >>> subj=(selinux)a:b:c:d/(apparmor)z >>> >>> would meet Steve's searchability requirements, but with significant >>> parsing performance penalties. >> I think "hideous format" sums it up nicely. Whatever we choose here >> we are likely going to be stuck with for some time and I'm near to >> 100% that multiplexing the labels onto a single field is going to be a >> disaster. > If the requirement is that subj= be searchable I don't see much of > an alternative to a Hideous format. If we can get past that, and say > that all subj_* have to be searchable we can avoid that set of issues. > Instead of: > > s = strstr(source, "subj=") > search_after_subj(s, ...); This example does a lot of hand waving in search_after_subj(...) regarding parsing the multiplexed LSM label. Unless we restrict the LSM label formats (which seems both wrong, and too late IMHO)

we have a parsing nightmare; can you write a safe multiplexed LSM label parser without knowledge of each LSM label format? Can you do that for each LSM without knowing their loaded policy? What happens when the policy and/or label format changes? What happens in a few years when another LSM is added to the kernel?

> we have > > s = source > for (i = 0; i < lsm_slots ; i++) { > s = strstr(s, "subj_") > if (!s) > break; > s = search_after_subj_(s, lsm_slot_name[i], ...) The hand waving here in search_after_subj_(...) is much less; essentially you just match "subj_X" and then you can take the field value as the LSM's label without having to know the format, the policy loaded, etc. It is both safer and doesn't require knowledge of the LSMs (the LSM "name" can be specified as a parameter to the search tool).

> There's enough ugly to go around either way. > And I'm not partial to either approach, but do would very > much like to get the code done so I can get on to the next > set of amazing challenges. > > Oh, and I don't want to pick on subj= as obj= has the exact same issues. Yes, I stopped talking about both subj and obj some time ago in this thread because I figure we can use the same approach for both.

On Wed, Jul 17, 2019 at 11:49 AM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 7/17/2019 5:14 AM, Paul Moore wrote: >> On Tue, Jul 16, 2019 at 7:47 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>> On 7/16/2019 4:13 PM, Paul Moore wrote: >>>> On Tue, Jul 16, 2019 at 6:18 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>>>> It sounds as if some variant of the Hideous format: >>>>> >>>>> subj=selinux='a:b:c:d',apparmor='z' >>>>> subj=selinux/a:b:c:d/apparmor/z >>>>> subj=(selinux)a:b:c:d/(apparmor)z >>>>> >>>>> would meet Steve's searchability requirements, but with significant >>>>> parsing performance penalties. >>>> I think "hideous format" sums it up nicely. Whatever we choose here >>>> we are likely going to be stuck with for some time and I'm near to >>>> 100% that multiplexing the labels onto a single field is going to be a >>>> disaster. >>> If the requirement is that subj= be searchable I don't see much of >>> an alternative to a Hideous format. If we can get past that, and say >>> that all subj_* have to be searchable we can avoid that set of issues. >>> Instead of: >>> >>> s = strstr(source, "subj=") >>> search_after_subj(s, ...); >> This example does a lot of hand waving in search_after_subj(...) >> regarding parsing the multiplexed LSM label. Unless we restrict the >> LSM label formats (which seems both wrong, and too late IMHO) > I don't think it's too late, and I think it would be healthy > to restrict LSM "contexts" to character sets that make command > line specification possible. Embedded newlines? Ewwww. That would imply that the delimiter you would choose for the multiplexed approach would be something odd (I think you suggested 0x02, or similar, earlier) which would likely require the multiplexed subj field to become a hex encoded field which would be very unfortunate in my opinion and would technically break with the current subj/obj field format spec. Picking a normal-ish delimiter, and restricting its use by LSMs seems wrong to me.

It's also worth noting that if you were to move subj/obj to hex encoded fields, in addition to causing a backwards compatibility problem, you completely kill the ability to look at the raw log data and make sense of the fields ... well, unless you can do the ascii hex conversion in your head on the fly.

>> we have >> a parsing nightmare; can you write a safe multiplexed LSM label parser >> without knowledge of each LSM label format? Can you do that for each >> LSM without knowing their loaded policy? What happens when the policy >> and/or label format changes? What happens in a few years when another >> LSM is added to the kernel? > I was intentionally hand-wavy because of those very issues. Then you should already realize why this is a terrible idea ;)

> Steve says that parsing is limited to "strstr()", so looking for > ":s7:" in the subject should work just as well with a Hideous > format as it does today, with the exception of false positives > where LSMs have label string overlaps. Today when you go to search through your audit log you know that a single LSM is providing subj labels, and you also know which LSM that happens to be, so searching on a given string, or substring, is easy and generally safe. In a multiplexed approach this becomes much more difficult, and depending on the search being done it could be misleading, perhaps even dangerous with complicated searches that exclude label substrings.

It's important to remember that Steve's strstr() comment only reflects his set of userspace tools. When you start talking about log aggregation and analytics, it seems very likely that there are other tools in use, likely with their own parsers that do much more complicated searches than a simple strstr() call.

> Where is the need to use a module specific label parser coming > from? Does the audit code parse SELinux contexts now? If you can't pick a "safe" delimiter that isn't included in any of the LSM label formats, how else do you know how to parse the multiplexed mess?

>>> we have >>> >>> s = source >>> for (i = 0; i < lsm_slots ; i++) { >>> s = strstr(s, "subj_") >>> if (!s) >>> break; >>> s = search_after_subj_(s, lsm_slot_name[i], ...) >> The hand waving here in search_after_subj_(...) is much less; >> essentially you just match "subj_X" and then you can take the field >> value as the LSM's label without having to know the format, the policy >> loaded, etc. It is both safer and doesn't require knowledge of the >> LSMs (the LSM "name" can be specified as a parameter to the search >> tool). > You can do that with the Hideous format as well. I wouldn't > say which would be easier without delving into the audit user > space. No, you can't. You still need to parse the multiplexed mess, that's the problem.

On Wed, 17 Jul 2019 at 16:02:16 -0700, Casey Schaufler wrote: > We've never had to think about having general rules on > what security modules do before, because with only one > active each could do whatever it wanted without fear of > conflict. If there is already a character that none of > the existing modules use, how would it be wrong to > reserve it? > > Smack disallows the four characters '"/\ because quoting > is too important to ignore and the likelyhood that someone > would confuse labels with paths seemed great. I sniffed > around a little, but couldn't find the sets for SELinux or > AppArmor. It seems we've been here before, when I added LinuxSecurityLabel to https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get... in D-Bus. Recapping the context for those who might have missed it: in D-Bus, processes communicate in a hub-and-spoke topology via a central message bus process, which forwards messages between the other processes. Some other IPC systems would call this a broker. As a result of this indirection, the message bus is the only process in the overall system that is in a position to ask the kernel for the identity of the other processes (credentials(7) and related topics like LSM labels) using unforgeable kernel-guaranteed socket options like SO_PEERCRED, SO_PEERSEC and SO_PEERGROUPS. This means that if two processes communicate via D-Bus and want to know each other's identities, they have to ask the message bus; so the message bus needs a representation for that information. For LSM labels, that representation is LinuxSecurityLabel, which is defined in terms of SO_PEERSEC. At the time that I defined LinuxSecurityLabel, nobody was willing to say for sure that the label was guaranteed to be ASCII or UTF-8 (which is part of the specification for the D-Bus STRING ('s') type), so I had to encode it as an arbitrary ARRAY of BYTE ('ay') rather than as a STRING. I was at least told that the label wouldn't contain embedded '\0', and that if there is a trailing '\0', I can safely canonicalize the string by removing it. Also, at the time that I did that, nobody was willing to say for sure that there was any particular correspondence between the security label obtained by reading /proc/self/attr/current and the security label obtained by getting the SO_PEERSEC socket option: in AppArmor, /proc/self/attr/current is something like "unconfined\n" whereas SO_PEERSEC is either "unconfined" or "unconfined\0" (I forget which), but the consensus seemed to be that there is no guarantee that the presence or absence of a trailing newline wouldn't be significant to some non-AppArmor LSM. If LSM stacking is going to lead to syntactic restrictions being imposed on security labels, please could someone add them to credentials(7) or some other suitable documentation so user-space developers can know where we stand, or tell me what the restrictions and guarantees are so I can propose a documentation patch?

Thanks, smcv

On Thu, 18 Jul 2019 at 09:13:52 -0700, Casey Schaufler wrote: > We have discussed what's currently being > called the "hideous" format, selinux='a:b:c:d',apparmor='x' which > in the past, and concluded that the compatibility issues would be too > great. I agree this might be too big a compat break for existing interfaces that were designed with the assumption that there can only be one "big" LSM at a time, like /proc/54321/attr/current and SO_PEERSEC. It would certainly break the current libapparmor, and presumably libselinux as well. However, I think it would be great to have multiple-"big"-LSM-aware replacements for those interfaces, which present the various LSMs as multiple parallel credentials.

I think it would also be valuable to take this opportunity to pin down what can and can't be in a label, to an extent where people who want to represent them in a similar encoding know what they can and can't assume about their format. For example, when dbus-daemon reports an unusual event (like rejecting a message due to policy rules or LSMs, or hitting a resource limit that isn't normally meant to be reached), the log entry contains miscellaneous information about the process for debugging purposes, and it would be good if we could include all the LSM labels in that string without ambiguity. This is essentially the same problem that the audit subsystem has, but with fewer constraints, since the audit subsystem has to meet externally-imposed security requirements but our equivalent is just a nice-to-have for debugging.

> Have you been following the discussions on setting a "display" value > to specify which LSM data is presented by /proc/self/attr/current and > SO_PEERSEC? Briefly, a process can write the name of the LSM it wants > to see data from to /proc/self/attr/display, and the aforementioned > interfaces will use that LSM. If no value has been set the first LSM > registered that uses any of these interfaces gets the nod. I'm vaguely aware of the discussion, but LSMs aren't a big part of my D-Bus maintainer role, so I'm afraid I can't keep up with all of it. Do you mean that if process 11111 writes (for example) "apparmor" into /proc/11111/attr/display, and then reads /proc/22222/attr/current or queries the SO_PEERSEC of a socket opened by process 22222, it will specifically see 22222's AppArmor label and not 22222's SELinux label? Or is the contents of /proc/22222/attr/current controlled by /proc/22222/attr/display?

How is this meant to work for generic LSM-aware user-space processes? If (for example) ps -Z 22222 wants to get both the AppArmor label and the SELinux label for process 22222, is it meant to write "apparmor" into attr/display, then read /proc/22222/attr/current, then write "selinux" to attr/display, then read /proc/22222/attr/current again? That sounds risky if another thread might be manipulating attr/display concurrently.

The D-Bus message bus/broker (reference implementation: dbus-daemon) is somewhat tricky because it is returning data on behalf of processes other than itself, so it would be difficult for it to choose a good value for "display": there's no reason why it wouldn't be responding to requests from NetworkManager that expect to see SELinux labels, and also requests from lxd that expect to see AppArmor labels. Obviously it can't put both in LinuxSecurityLabel without the same compatibility issues you're discussing.

Also note that dbus-daemon is trusted but mostly unprivileged - it starts as root, then drops privileges to a system user normally called messagebus, dbus or _dbus for its normal operation (although it does retain CAP_AUDIT_WRITE) - so it can't carry out privileged operations on other processes' /proc entries, if that's what the API requires.

I would strongly prefer it if we could get this information from the kernel in a way that is Linux-specific but LSM-agnostic, without having to link to libapparmor, libselinux, libsmack and everyone else's favourite LSM library. At the moment we only need to link to libraries for the LSMs where dbus-daemon can carry out mediation (asking the LSM whether to accept or reject messages), and we don't need the libraries if we are just passing through identity information.

I would also prefer it if we can get this information from SO_PEERSEC (or some newer SO_PEERSEC replacement) without having to manipulate ambient/implicit state like attr/display; but dbus-daemon is single-threaded, so if we must do that, it wouldn't be *so* horrible.

Ideally I would like to be able to get all the LSM labels in O(1) syscalls. Perhaps something with the same (buffer,length) kernel <-> user-space API as SO_PEERSEC and SO_PEERGROUPS, but instead of returning a single \0-terminated string, it could return either the "hideous" format, or a byte-blob that looks something like this? char buffer[ENOUGH_LENGTH] = { 0 }; socklen_t len = sizeof (buffer); char[] expected = "apparmor=unconfined\0" "selinux=system_u:system_r:init_t:s0\0" "\0" ; getsockopt (fd, SOL_SOCKET, SO_PEERSECLABELS, &buffer, &length); /* should return 0 */ /* now buffer should have the same bytes as expected, ending with * "\0\0" */ (Obviously in real life you'd have a retry loop to get the length right, like the SO_PEERSEC code in dbus does.)

Because GetConnectionCredentials() is extensible, if there is some way to enumerate all the security labels and get their values individually, we could have (pseudocode) GetConnectionCredentials(":1.1") -> { "UnixUserID": 0, "ProcessID": 1, "LinuxSecurityLabel.apparmor": "unconfined", "LinuxSecurityLabel.selinux": "system_u:system_r:init_t:s0", "LinuxSecurityLabel": "unconfined", /* deprecated */ } or (using D-Bus' structured type system) GetConnectionCredentials(":1.1") -> { "UnixUserID": 0, "ProcessID": 1, "LinuxSecurityLabels": { "apparmor": "unconfined", "selinux": "system_u:system_r:init_t:s0", }, "LinuxSecurityLabel": "unconfined", /* deprecated */ } with LinuxSecurityLabel showing the first LSM registered for backwards compatibility? Or we could make LinuxSecurityLabel always be in the "hideous" format if you chose to go that way in the kernel interfaces: it's defined in terms of SO_PEERSEC, so whatever you do at the kernel level, D-Bus should mimic that.

smcv

Thanks for considering user-space in this, and sorry if I'm hijacking this thread a bit (but I think some of the things I'm raising might be equally applicable for audit subjects).

On Fri, 19 Jul 2019 at 09:29:17 -0700, Casey Schaufler wrote: > On 7/19/2019 5:15 AM, Simon McVittie wrote: >> However, I think it would be great to have multiple-"big"-LSM-aware >> replacements for those interfaces, which present the various LSMs as >> multiple parallel credentials. > Defining what would go into liblsm* is a task that has fallen to > the chicken/egg paradox. We can't really define how the user-space > should work without knowing how the kernel will work, and we can't > solidify how the kernel will work until we know what user-space > can use. I was hoping the syscall wrappers in glibc would be a viable user-space interface to the small amount of LSM stuff that dbus needs to use in an LSM-agnostic way. That's what we use in dbus at the moment (in practice just getsockopt, but I'd also be reading /proc/self/attr/current if there was a specification for how to normalize it to match SO_PEERSEC results) and it's no harder than the rest of the syscall-level APIs.

A single LSM-agnostic shared library would be the next best thing from my point of view.

> An option that hasn't been discussed is a display option to provide > the Hideous format for applications that know that's what they want. > Write "hideous" into /proc/self/attr/display, and from then on you > get selinux='a:b:c:d',apparmor='z'. This could be used widely in liblsm > interfaces. If the way to parse/split it is documented, then this would be easier for dbus-daemon than continually resetting attr/display. It would be especially good if you can document a way to find out which one of the many labels would have been seen by an older user-space process that never wrote to attr/display ("it's the first one in the list" would be fine), so that we can put that one in our backwards-compatible API to clients.

Or, alternatively, we could pass it on directly to our clients and let *them* parse it (possibly by using liblsm), the same way AppArmor-aware D-Bus clients have to know how to use either aa_splitcon() or their own parsing to go from the raw SO_PEERSEC result "/usr/bin/firefox (enforce)" to the pair ("/usr/bin/firefox", "enforce") that they probably actually wanted. >> Do you mean that if process 11111 writes (for example) "apparmor" into >> /proc/11111/attr/display, and then reads /proc/22222/attr/current >> or queries the SO_PEERSEC of a socket opened by process 22222, >> it will specifically see 22222's AppArmor label and not 22222's SELinux >> label? > Process 11111 would see the AppArmor label when reading > /proc/22222/attr/current. The display value is controlled > by process 11111 so that it can control what data it wants > to see. OK, that's what I'd hoped. > The display is set at the task level, so should be thread safe. OK, good. However, thinking more about this, I have other concerns: * In library code that can be used by a thread (task) that also uses other arbitrary libraries, or in an executable that uses libraries that might be interested in LSMs, the only safe way to deal with attr/display would be this sequence: - write desired value to /proc/self/attr/display - immediately read /proc/other/attr/current or query SO_PEERSEC and it would not be safe to rely on writing /proc/self/attr/display just once at startup, because some other library might have already changed it between startup and the actual read. Paradoxically, this maximizes the chance of breaking a reader that was relying on writing /proc/self/attr/display once during startup. * If an async signal handler needs to know a LSM label for whatever reason, it will break anything in the same thread that was relying on that sequence, because it might have interrupted them between their write and their read: main execution path signal handler ------------------- -------------- write "apparmor" to attr/display (interrupted by async signal) write "selinux" to attr/display read attr/current or SO_PEERSEC do other stuff with SELinux label return (resumes) read attr/current or SO_PEERSEC expect an AppArmor label get a SELinux label sadness ensues Of course it's probably crazy for an async signal handler to do this... but people do lots of odd things in async signal handlers, and open(), read(), write(), getsockopt() are all async-signal-safe functions, so it's at least arguably valid.

> Writing to display does not require privilege, as it affects only > the current process. The display is inherited on fork and reset on > a privileged exec. Another concern here: are you sure it shouldn't be reset on *any* exec?

Lots of programs (including dbus-daemon) fork-and-exec arbitrary child processes that come from a different codebase not under our control and aren't necessarily LSM-stacking-aware. I don't really want to have to reset /proc/self/attr/display in our increasingly crowded after-fork-but-before-exec code path (which, according to POSIX, is not a safe place to invoke any non-async-signal-safe function, so we can't easily do error handling if something goes wrong there).

Is there any possibility of having a parallel kernel API that, if it exists, always returns the whole stack, maybe something like /proc/<pid>/attr/current_stack and the SO_PEERSECLABELS that I suggested previously,

instead of repurposing /proc/<pid>/attr/current and SO_PEERSEC to have contents that vary according to ambient process state in their reader?

(Bonus points if they are documented/defined with a particular syntactic normalization this time, unlike the situation with /proc/<pid>/attr/current and SO_PEERSEC where in principle you need LSM-specific knowledge to know whether a trailing "\n" or "\0" is safe to discard.)

smcv

On Fri, 19 Jul 2019 at 13:02:24 -0700, Casey Schaufler wrote: > On 7/19/2019 11:47 AM, Simon McVittie wrote: >> I was hoping the syscall wrappers in glibc would be a viable user-space >> interface to the small amount of LSM stuff that dbus needs to use in an >> LSM-agnostic way. > I don't see how to do that without making the Fedora and Ubuntu user space > environments [not] remain functional. What I was thinking of was a second, parallel kernel <-> user-space interface (like the SO_PEERSECLABELS that I suggested) for future/updated user-space components. SO_PEERSEC would continue to return some hopefully-backwards-compatible thing, but would be deprecated, because it cannot fully represent the reality of LSM stacking while remaining backwards-compatible.

> I see display being used in scripts: > > echo apparmor > /proc/self/attr/display > apparmor-do-stuff --options --deamon > > much more than inside new or updated programs. Note that this implicitly relies on echo being a shell builtin, which is common but not guaranteed (I don't think). It would work in bash or dash, though.

If apparmor-do-stuff no longer works, and you have to wrap a shell script around it, isn't that the same amount of user-space breakage as if apparmor-do-stuff no longer works and you have to install a newer version that does work?

Either way, the sysadmin must take action to change user-space components. I think the attr/display thing only reduces the magnitude of the user-space changes required to catch up, and doesn't eliminate the fact that those changes were needed.

>> Lots of programs (including dbus-daemon) fork-and-exec arbitrary >> child processes that come from a different codebase not under our >> control and aren't necessarily LSM-stacking-aware. I don't really want >> to have to reset /proc/self/attr/display in our increasingly crowded >> after-fork-but-before-exec code path > My hope is that new and updated programs will have to tools > they need to get it right, and that those that don't won't > fall over on a well configured system. The problem I see here is that if we assume dbus-daemon is a new/updated program that has set /proc/self/attr/display = "hideous" in order to get the full stack of labels for its peer processes, then it will be causing side-effects on its separately-maintained child processes - they will no longer be able to benefit from the backwards-compatility thing where /proc/self/attr/display (effectively) defaults to the first LSM that has labels, because dbus-daemon overrode that (unless dbus-daemon takes action to reverse it between fork and exec). This partially defeats the semi-backwards-compatible handling of the existing kernel interfaces.

If dbus-daemon could read SO_PEERSECLABELS instead of SO_PEERSEC and read /proc/<pid>/attr/current_stack instead of /proc/<pid>/attr/current, leaving /proc/self/attr/display untouched, then this concern would go away.

Similarly, dbus-daemon can be linked to libselinux and/or libapparmor (on Debian it's linked to both, even in the non-stackable present, and the right one for the kernel configuration is chosen at runtime). If one of those libraries wrote to /proc/self/attr/display, then the rest of dbus-daemon's main thread and all child processes would implicitly be getting the result of that - even if dbus-daemon itself had not yet been updated for stacked LSMs (in which case it cannot be expected to reverse their action between fork and exec, because it's an older codebase that doesn't yet know that "big" LSMs can be stacked).

So I think libselinux and libapparmor should be enhanced to use new kernel interfaces that get the label they want to get (either just that label, or all the labels), instead of being enhanced to write /proc/self/attr/display to change the meaning of old kernel interfaces. Otherwise they can break other code in their process or their subprocesses.

>> instead of repurposing /proc/<pid>/attr/current >> and SO_PEERSEC to have contents that vary according to ambient process >> state in their reader? > In addition, yes. Instead of? I don't think that we can have a > backward compatibility story that flies without it. Consider only SELinux and AppArmor for a moment (I know there are other "big" LSMs like Smack, but this same reasoning applies to any pair, with appropriate search-and-replace on their names). Neither SELinux nor AppArmor: there are no labels, nothing changed. AppArmor is the only "big" LSM in the stack (Ubuntu): previously, the label was the AppArmor label; now, if attr/display is not altered, the label is the one used by the first "big" LSM in the stack, which is AppArmor. Nothing changed. SELinux is the only "big" LSM in the stack (Red Hat): same as for AppArmor being the only "big" LSM in the stack, but with s/AppArmor/SELinux/. SELinux and AppArmor stacked: this is a situation that could not exist before, so distro/sysadmin action must have been necessary to make it happen. However much ambient process state is invented, I don't see any way to make both SELinux and AppArmor user-space work without modifications: at least one of them (the one that is second in the stack) has to use new kernel interfaces, or alter attr/display to change the meaning of the old kernel interfaces, or something similar, to get the second LSM's labels. So distro/sysadmin action in user-space is also going to be necessary here whatever happens - backward compatibility has already been broken, it's only a question of how intrusive the user-space changes are. Is it really so much worse if the distro/sysadmin action taken to update user-space has to take the form of using new kernel interfaces that always do the same thing, rather than changing the meaning of old kernel interfaces?

smcv

> We've never had to think about having general rules on > what security modules do before, because with only one > active each could do whatever it wanted without fear of > conflict. If there is already a character that none of > the existing modules use, how would it be wrong to > reserve it? "We've never had to think about having general rules on what security modules do before..." We famously haven't imposed restrictions on the label format before now, and this seems like a pretty poor reason to start.

On 7/22/2019 1:50 PM, James Morris wrote: > On Fri, 19 Jul 2019, Paul Moore wrote: > >>> We've never had to think about having general rules on >>> what security modules do before, because with only one >>> active each could do whatever it wanted without fear of >>> conflict. If there is already a character that none of >>> the existing modules use, how would it be wrong to >>> reserve it? >> "We've never had to think about having general rules on what security >> modules do before..." >> >> We famously haven't imposed restrictions on the label format before >> now, and this seems like a pretty poor reason to start. > Agreed. In a follow on thread https://www.spinics.net/lists/linux-security-module/msg29996.html we've been discussing the needs of dbus-daemon in a multiple LSM environment. I suggest that if supporting dbus well is assisted by making reasonable restrictions on what constitutes a valid LSM "context" that we have a good reason. While there are ways to present groups of arbitrary hunks of data, why would we want to?

On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > I suggest that if supporting dbus well is assisted by > making reasonable restrictions on what constitutes a valid LSM > "context" that we have a good reason. I continue to believe that restrictions on the label format are a bad idea

On Mon, 22 Jul 2019 at 18:30:35 -0400, Paul Moore wrote: > On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > > I suggest that if supporting dbus well is assisted by > > making reasonable restrictions on what constitutes a valid LSM > > "context" that we have a good reason. > > I continue to believe that restrictions on the label format are a bad > idea Does this include the restriction "the label does not include \0", which is an assumption that dbus is already relying on since I checked it in the thread around <https://marc.info/?l=linux-security-module&m=142323508321029&w=2&... Or is that restriction so fundamental that it's considered OK?

The subj_X approach is still backwards compatible, the difference is that old versions of the tools get a "?" for the LSM creds which is a rather sane way of indicating something is different.

Once again, I believe that the subj_X approach is going to be faster than safely parsing the multiplexed format.

> >>>> the following (something between option #2 and #3): > >>>> subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux > >>>> > >>>> subj2=<selinux_label> ... > >>> If it's not a subj= field why use the indirection? > >>> > >>> subj_smack=<smack_label> subj_selinux=<selinux_label>