Unique audit record type ranges for individual LSMs

Unique audit record type ranges for individual LSMs

[Tyler Hicks]

[-- Attachment #1.1: Type: text/plain, Size: 1986 bytes --]

Hello - The AppArmor project would like for AppArmor audit records to be
supported by the audit-userspace tools, such as ausearch, but it
requires some coordination between the linux-security-module and
linux-audit lists. This was raised as a feature request years ago in
Ubuntu and more recently in Debian:

  https://launchpad.net/bugs/1117804
  https://bugs.debian.org/872726

The quick summary of the problem at hand is that the audit-userspace
project requires that each LSM use a unique record type range for audit
records while the kernel's common_lsm_audit() function uses the same
record type (1400) for all records. SELinux, AppArmor, and SMACK are all
using common_lsm_audit() today and, therefore, the 1400-1499 range.

While it will be potentially painful to switch, the AppArmor project is
considering to use a unique range in order for audit-userspace to
support AppArmor audit records. IMHO, SMACK would be free to continue
using 1400-1499 as long as they don't need audit-userspace support and
SELinux would continue using 1400-1499.

Steve Grubb previously told me that he intends 1500-1599 to be used by
AppArmor:

  https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html


John Johansen tells me that AppArmor previously used the 1500-1599 range
before AppArmor was upstreamed.

There's a conflicting comment in the kernel stating that 1500-1599 is to
by used by kernel LSPP events. As far as I can tell, there were never
any kernel LSPP events that used the range. Steve is the one that added
that comment so I think it is a safe range for AppArmor to use:

  https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17

Considering audit-userspace's stance, does the LSM community agree that
common_lsm_audit() should be modified to accept an audit record type
parameter to pass on to audit_log_start()?

If so, does everyone agree that 1500-1599 would be acceptable for
AppArmor to use?

Tyler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Unique audit record type ranges for individual LSMs

[Casey Schaufler]

On 12/6/2017 9:51 AM, Tyler Hicks wrote:
> Hello - The AppArmor project would like for AppArmor audit records to be
> supported by the audit-userspace tools, such as ausearch, but it
> requires some coordination between the linux-security-module and
> linux-audit lists. This was raised as a feature request years ago in
> Ubuntu and more recently in Debian:
>
>   https://launchpad.net/bugs/1117804
>   https://bugs.debian.org/872726
>
> The quick summary of the problem at hand is that the audit-userspace
> project requires that each LSM use a unique record type range for audit
> records while the kernel's common_lsm_audit() function uses the same
> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
> using common_lsm_audit() today and, therefore, the 1400-1499 range.

My, but this is a rat's nest, isn't it? The constants, such as AUDIT_MAC_STATUS,
look as if they are intended to be generic. But the comment says the range is
for SELinux. Some of the events, including AUDIT_MAC_MAP_ADD *are* generic, in
that they are from the netlbl subsystem. But some, AUDIT_AVC being paramount,
are indeed SELinux specific.

> While it will be potentially painful to switch, the AppArmor project is
> considering to use a unique range in order for audit-userspace to
> support AppArmor audit records. IMHO, SMACK would be free to continue
> using 1400-1499 as long as they don't need audit-userspace support and
> SELinux would continue using 1400-1499.

Aside from the comment that says 1400-1499 are for SELinux, and the three
events (1400-1402) that are SELinux specific, the events really are general.
Why not add the AppArmor specifics to the 1400 range? Give them a generic
sounding name and you'll achieve consistency. Change the comment to say
"Security Module use" instead of "SELinux use".

> Steve Grubb previously told me that he intends 1500-1599 to be used by
> AppArmor:
>
>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
>
>
> John Johansen tells me that AppArmor previously used the 1500-1599 range
> before AppArmor was upstreamed.
>
> There's a conflicting comment in the kernel stating that 1500-1599 is to
> by used by kernel LSPP events. As far as I can tell, there were never
> any kernel LSPP events that used the range. Steve is the one that added
> that comment so I think it is a safe range for AppArmor to use:
>
>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17
>
> Considering audit-userspace's stance, does the LSM community agree that
> common_lsm_audit() should be modified to accept an audit record type
> parameter to pass on to audit_log_start()?
>
> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?

Why not change the comment and continue to use the 1400 range, adding
events as necessary?

>
> Tyler
>

--
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

Re: Unique audit record type ranges for individual LSMs

[Casey Schaufler]

On 12/6/2017 9:51 AM, Tyler Hicks wrote:
> Hello - The AppArmor project would like for AppArmor audit records to be
> supported by the audit-userspace tools, such as ausearch, but it
> requires some coordination between the linux-security-module and
> linux-audit lists. This was raised as a feature request years ago in
> Ubuntu and more recently in Debian:
>
>   https://launchpad.net/bugs/1117804
>   https://bugs.debian.org/872726
>
> The quick summary of the problem at hand is that the audit-userspace
> project requires that each LSM use a unique record type range for audit
> records while the kernel's common_lsm_audit() function uses the same
> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
> using common_lsm_audit() today and, therefore, the 1400-1499 range.

My, but this is a rat's nest, isn't it? The constants, such as AUDIT_MAC_STATUS,
look as if they are intended to be generic. But the comment says the range is
for SELinux. Some of the events, including AUDIT_MAC_MAP_ADD *are* generic, in
that they are from the netlbl subsystem. But some, AUDIT_AVC being paramount,
are indeed SELinux specific.

> While it will be potentially painful to switch, the AppArmor project is
> considering to use a unique range in order for audit-userspace to
> support AppArmor audit records. IMHO, SMACK would be free to continue
> using 1400-1499 as long as they don't need audit-userspace support and
> SELinux would continue using 1400-1499.

Aside from the comment that says 1400-1499 are for SELinux, and the three
events (1400-1402) that are SELinux specific, the events really are general.
Why not add the AppArmor specifics to the 1400 range? Give them a generic
sounding name and you'll achieve consistency. Change the comment to say
"Security Module use" instead of "SELinux use".

> Steve Grubb previously told me that he intends 1500-1599 to be used by
> AppArmor:
>
>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
>
>
> John Johansen tells me that AppArmor previously used the 1500-1599 range
> before AppArmor was upstreamed.
>
> There's a conflicting comment in the kernel stating that 1500-1599 is to
> by used by kernel LSPP events. As far as I can tell, there were never
> any kernel LSPP events that used the range. Steve is the one that added
> that comment so I think it is a safe range for AppArmor to use:
>
>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17
>
> Considering audit-userspace's stance, does the LSM community agree that
> common_lsm_audit() should be modified to accept an audit record type
> parameter to pass on to audit_log_start()?
>
> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?

Why not change the comment and continue to use the 1400 range, adding
events as necessary?

>
> Tyler
>

Re: Unique audit record type ranges for individual LSMs

[Tyler Hicks]

[-- Attachment #1.1: Type: text/plain, Size: 3698 bytes --]

On 12/06/2017 12:47 PM, Casey Schaufler wrote:
> On 12/6/2017 9:51 AM, Tyler Hicks wrote:
>> Hello - The AppArmor project would like for AppArmor audit records to be
>> supported by the audit-userspace tools, such as ausearch, but it
>> requires some coordination between the linux-security-module and
>> linux-audit lists. This was raised as a feature request years ago in
>> Ubuntu and more recently in Debian:
>>
>>   https://launchpad.net/bugs/1117804
>>   https://bugs.debian.org/872726
>>
>> The quick summary of the problem at hand is that the audit-userspace
>> project requires that each LSM use a unique record type range for audit
>> records while the kernel's common_lsm_audit() function uses the same
>> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
>> using common_lsm_audit() today and, therefore, the 1400-1499 range.
> 
> My, but this is a rat's nest, isn't it? The constants, such as AUDIT_MAC_STATUS,
> look as if they are intended to be generic. But the comment says the range is
> for SELinux. Some of the events, including AUDIT_MAC_MAP_ADD *are* generic, in
> that they are from the netlbl subsystem. But some, AUDIT_AVC being paramount,
> are indeed SELinux specific.

It is a rat's nest, which is why the Ubuntu bug above has lingered for
so long.

Good point regarding AUDIT_MAC_MAP_ADD being generic.

> 
>> While it will be potentially painful to switch, the AppArmor project is
>> considering to use a unique range in order for audit-userspace to
>> support AppArmor audit records. IMHO, SMACK would be free to continue
>> using 1400-1499 as long as they don't need audit-userspace support and
>> SELinux would continue using 1400-1499.
> 
> Aside from the comment that says 1400-1499 are for SELinux, and the three
> events (1400-1402) that are SELinux specific, the events really are general.
> Why not add the AppArmor specifics to the 1400 range? Give them a generic
> sounding name and you'll achieve consistency. Change the comment to say
> "Security Module use" instead of "SELinux use".

I would be alright with this solution. We could even claim 1400-1599 or
even 1400-1699 for "Security Module use" if we thought 100 record types
may not be enough in the future.

I could see how there may be a desire for each LSM to have their own
blocks of 100 where they can assign record types freely without
coordination with LSM maintainers but I don't feel like new record types
come around often enough for this to matter much.

> 
>> Steve Grubb previously told me that he intends 1500-1599 to be used by
>> AppArmor:
>>
>>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
>>
>>
>> John Johansen tells me that AppArmor previously used the 1500-1599 range
>> before AppArmor was upstreamed.
>>
>> There's a conflicting comment in the kernel stating that 1500-1599 is to
>> by used by kernel LSPP events. As far as I can tell, there were never
>> any kernel LSPP events that used the range. Steve is the one that added
>> that comment so I think it is a safe range for AppArmor to use:
>>
>>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17
>>
>> Considering audit-userspace's stance, does the LSM community agree that
>> common_lsm_audit() should be modified to accept an audit record type
>> parameter to pass on to audit_log_start()?
>>
>> If so, does everyone agree that 1500-1599 would be acceptable for
>> AppArmor to use?
> 
> Why not change the comment and continue to use the 1400 range, adding
> events as necessary?

I don't have any problems with that but I'd like Steve Grubb to weigh in
on it.

Tyler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 12:51:26 PM EST Tyler Hicks wrote:
> Hello - The AppArmor project would like for AppArmor audit records to be
> supported by the audit-userspace tools, such as ausearch, but it
> requires some coordination between the linux-security-module and
> linux-audit lists. This was raised as a feature request years ago in
> Ubuntu and more recently in Debian:
> 
>   https://launchpad.net/bugs/1117804
>   https://bugs.debian.org/872726
> 
> The quick summary of the problem at hand is that the audit-userspace
> project requires that each LSM use a unique record type range for audit
> records while the kernel's common_lsm_audit() function uses the same
> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
> using common_lsm_audit() today and, therefore, the 1400-1499 range.
> 
> While it will be potentially painful to switch, the AppArmor project is
> considering to use a unique range in order for audit-userspace to
> support AppArmor audit records. IMHO, SMACK would be free to continue
> using 1400-1499 as long as they don't need audit-userspace support and
> SELinux would continue using 1400-1499.
> 
> Steve Grubb previously told me that he intends 1500-1599 to be used by
> AppArmor:
> 
>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
> 
> 
> John Johansen tells me that AppArmor previously used the 1500-1599 range
> before AppArmor was upstreamed.

Yes, this is what I have:

#define AUDIT_AA                        1500    /* Not upstream yet */
#define AUDIT_APPARMOR_AUDIT            1501
#define AUDIT_APPARMOR_ALLOWED          1502
#define AUDIT_APPARMOR_DENIED           1503
#define AUDIT_APPARMOR_HINT             1504
#define AUDIT_APPARMOR_STATUS           1505
#define AUDIT_APPARMOR_ERROR            1506


> There's a conflicting comment in the kernel stating that 1500-1599 is to
> by used by kernel LSPP events. As far as I can tell, there were never
> any kernel LSPP events that used the range.

This seems like an erroneous comment in audit.h.


> Steve is the one that added that comment so I think it is a safe range for
> AppArmor to use:
> 
>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17

I think this commit predates the agreement on the apparmor range and a 
followup assignment in the kernel was never done.


> Considering audit-userspace's stance, does the LSM community agree that
> common_lsm_audit() should be modified to accept an audit record type
> parameter to pass on to audit_log_start()?

This is part of the problem. I get an AVC from selinux like this:

type=AVC msg=audit(1512997597.761:271): avc:  denied  { append } for  pid=1304 
comm="mail" name="dead.letter" dev="nvme0n1p2" ino=17 
scontext=system_u:system_r:fsdaemon_t:s0 
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file permissive=0

Nowhere in this does it tell me this is from the selinux LSM. So, that means 
it is implicit in the event number. Its important for me to know what LSM sent 
this so that it can be parsed correctly. If every LSM uses the same event 
numbers as selinux, then we probably have parsing problems because they are 
being parsed like selinux events and the wording/reporting probably does not 
make sense.


> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?

In the absence of any way to determine what I'm dealing with, separating LSMs 
by event number is best.

Also, I don't get or see any events from these other LSM's. I can't reproduce 
any bugs or verify the correctness of any reports or searches. Not that I 
don't want to support other LSM's, but I need someone else to check it and 
make sure it's doing  the right thing. Patches are welcome.

-Steve
--
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

Re: Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 12:51:26 PM EST Tyler Hicks wrote:
> Hello - The AppArmor project would like for AppArmor audit records to be
> supported by the audit-userspace tools, such as ausearch, but it
> requires some coordination between the linux-security-module and
> linux-audit lists. This was raised as a feature request years ago in
> Ubuntu and more recently in Debian:
> 
>   https://launchpad.net/bugs/1117804
>   https://bugs.debian.org/872726
> 
> The quick summary of the problem at hand is that the audit-userspace
> project requires that each LSM use a unique record type range for audit
> records while the kernel's common_lsm_audit() function uses the same
> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
> using common_lsm_audit() today and, therefore, the 1400-1499 range.
> 
> While it will be potentially painful to switch, the AppArmor project is
> considering to use a unique range in order for audit-userspace to
> support AppArmor audit records. IMHO, SMACK would be free to continue
> using 1400-1499 as long as they don't need audit-userspace support and
> SELinux would continue using 1400-1499.
> 
> Steve Grubb previously told me that he intends 1500-1599 to be used by
> AppArmor:
> 
>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
> 
> 
> John Johansen tells me that AppArmor previously used the 1500-1599 range
> before AppArmor was upstreamed.

Yes, this is what I have:

#define AUDIT_AA                        1500    /* Not upstream yet */
#define AUDIT_APPARMOR_AUDIT            1501
#define AUDIT_APPARMOR_ALLOWED          1502
#define AUDIT_APPARMOR_DENIED           1503
#define AUDIT_APPARMOR_HINT             1504
#define AUDIT_APPARMOR_STATUS           1505
#define AUDIT_APPARMOR_ERROR            1506


> There's a conflicting comment in the kernel stating that 1500-1599 is to
> by used by kernel LSPP events. As far as I can tell, there were never
> any kernel LSPP events that used the range.

This seems like an erroneous comment in audit.h.


> Steve is the one that added that comment so I think it is a safe range for
> AppArmor to use:
> 
>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17

I think this commit predates the agreement on the apparmor range and a 
followup assignment in the kernel was never done.


> Considering audit-userspace's stance, does the LSM community agree that
> common_lsm_audit() should be modified to accept an audit record type
> parameter to pass on to audit_log_start()?

This is part of the problem. I get an AVC from selinux like this:

type=AVC msg=audit(1512997597.761:271): avc:  denied  { append } for  pid=1304 
comm="mail" name="dead.letter" dev="nvme0n1p2" ino=17 
scontext=system_u:system_r:fsdaemon_t:s0 
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file permissive=0

Nowhere in this does it tell me this is from the selinux LSM. So, that means 
it is implicit in the event number. Its important for me to know what LSM sent 
this so that it can be parsed correctly. If every LSM uses the same event 
numbers as selinux, then we probably have parsing problems because they are 
being parsed like selinux events and the wording/reporting probably does not 
make sense.


> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?

In the absence of any way to determine what I'm dealing with, separating LSMs 
by event number is best.

Also, I don't get or see any events from these other LSM's. I can't reproduce 
any bugs or verify the correctness of any reports or searches. Not that I 
don't want to support other LSM's, but I need someone else to check it and 
make sure it's doing  the right thing. Patches are welcome.

-Steve

Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> > While it will be potentially painful to switch, the AppArmor project is
> > considering to use a unique range in order for audit-userspace to
> > support AppArmor audit records. IMHO, SMACK would be free to continue
> > using 1400-1499 as long as they don't need audit-userspace support and
> > SELinux would continue using 1400-1499.
> 
> Aside from the comment that says 1400-1499 are for SELinux, and the three
> events (1400-1402) that are SELinux specific, the events really are general.
> Why not add the AppArmor specifics to the 1400 range? Give them a generic
> sounding name and you'll achieve consistency. Change the comment to say
> "Security Module use" instead of "SELinux use".

I really don't know what the status is for user space support on the other 
LSMs. I couldn't tell you if the searching/reporting are broken or working 
just fine.

Additionally, there is auditctl which has very selinux specific field options 
to audit on a variety of pieces of the labels. Does this make sense for other 
LSMs? Do other LSMs have different needs? I really have no idea.

But one thing for sure...if we combine them all, I expect patches are needed 
for user space. By separating them out by event number or some identifier like 
lsm=, then we can have lsm specific fixups if necessary.

-Steve
--
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

Re: Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> > While it will be potentially painful to switch, the AppArmor project is
> > considering to use a unique range in order for audit-userspace to
> > support AppArmor audit records. IMHO, SMACK would be free to continue
> > using 1400-1499 as long as they don't need audit-userspace support and
> > SELinux would continue using 1400-1499.
> 
> Aside from the comment that says 1400-1499 are for SELinux, and the three
> events (1400-1402) that are SELinux specific, the events really are general.
> Why not add the AppArmor specifics to the 1400 range? Give them a generic
> sounding name and you'll achieve consistency. Change the comment to say
> "Security Module use" instead of "SELinux use".

I really don't know what the status is for user space support on the other 
LSMs. I couldn't tell you if the searching/reporting are broken or working 
just fine.

Additionally, there is auditctl which has very selinux specific field options 
to audit on a variety of pieces of the labels. Does this make sense for other 
LSMs? Do other LSMs have different needs? I really have no idea.

But one thing for sure...if we combine them all, I expect patches are needed 
for user space. By separating them out by event number or some identifier like 
lsm=, then we can have lsm specific fixups if necessary.

-Steve

Unique audit record type ranges for individual LSMs

[Casey Schaufler]

On 12/11/2017 7:44 AM, Steve Grubb wrote:
> On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
>>> While it will be potentially painful to switch, the AppArmor project is
>>> considering to use a unique range in order for audit-userspace to
>>> support AppArmor audit records. IMHO, SMACK would be free to continue
>>> using 1400-1499 as long as they don't need audit-userspace support and
>>> SELinux would continue using 1400-1499.
>> Aside from the comment that says 1400-1499 are for SELinux, and the three
>> events (1400-1402) that are SELinux specific, the events really are general.
>> Why not add the AppArmor specifics to the 1400 range? Give them a generic
>> sounding name and you'll achieve consistency. Change the comment to say
>> "Security Module use" instead of "SELinux use".
> I really don't know what the status is for user space support on the other 
> LSMs. I couldn't tell you if the searching/reporting are broken or working 
> just fine.

Understood. And it's only going to get worse with module stacking.

> Additionally, there is auditctl which has very selinux specific field options 
> to audit on a variety of pieces of the labels. Does this make sense for other 
> LSMs? Do other LSMs have different needs? I really have no idea.

Three of the record types are SELinux specific. Nine are netlabel, which are
not SELinux specific, or at least shouldn't be. Three are about setting state.
We could have different audit records for Smack setting netlabel maps from the
one SELinux uses, but that seems wrong.

> But one thing for sure...if we combine them all, I expect patches are needed 
> for user space. By separating them out by event number or some identifier like 
> lsm=, then we can have lsm specific fixups if necessary.

It seems to me that adding proper support for security modules
other than SELinux is going to be a project. That's true regardless
of how the messages are numbered and whether or not we have generic
messages.

> -Steve
> --
> 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
>

--
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

Re: Unique audit record type ranges for individual LSMs

[Casey Schaufler]

On 12/11/2017 7:44 AM, Steve Grubb wrote:
> On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
>>> While it will be potentially painful to switch, the AppArmor project is
>>> considering to use a unique range in order for audit-userspace to
>>> support AppArmor audit records. IMHO, SMACK would be free to continue
>>> using 1400-1499 as long as they don't need audit-userspace support and
>>> SELinux would continue using 1400-1499.
>> Aside from the comment that says 1400-1499 are for SELinux, and the three
>> events (1400-1402) that are SELinux specific, the events really are general.
>> Why not add the AppArmor specifics to the 1400 range? Give them a generic
>> sounding name and you'll achieve consistency. Change the comment to say
>> "Security Module use" instead of "SELinux use".
> I really don't know what the status is for user space support on the other 
> LSMs. I couldn't tell you if the searching/reporting are broken or working 
> just fine.

Understood. And it's only going to get worse with module stacking.

> Additionally, there is auditctl which has very selinux specific field options 
> to audit on a variety of pieces of the labels. Does this make sense for other 
> LSMs? Do other LSMs have different needs? I really have no idea.

Three of the record types are SELinux specific. Nine are netlabel, which are
not SELinux specific, or at least shouldn't be. Three are about setting state.
We could have different audit records for Smack setting netlabel maps from the
one SELinux uses, but that seems wrong.

> But one thing for sure...if we combine them all, I expect patches are needed 
> for user space. By separating them out by event number or some identifier like 
> lsm=, then we can have lsm specific fixups if necessary.

It seems to me that adding proper support for security modules
other than SELinux is going to be a project. That's true regardless
of how the messages are numbered and whether or not we have generic
messages.

> -Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Monday, December 11, 2017 3:56:35 PM EST Casey Schaufler wrote:
> On 12/11/2017 7:44 AM, Steve Grubb wrote:
> > On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> >>> While it will be potentially painful to switch, the AppArmor project is
> >>> considering to use a unique range in order for audit-userspace to
> >>> support AppArmor audit records. IMHO, SMACK would be free to continue
> >>> using 1400-1499 as long as they don't need audit-userspace support and
> >>> SELinux would continue using 1400-1499.
> >> 
> >> Aside from the comment that says 1400-1499 are for SELinux, and the three
> >> events (1400-1402) that are SELinux specific, the events really are
> >> general. Why not add the AppArmor specifics to the 1400 range? Give them
> >> a generic sounding name and you'll achieve consistency. Change the
> >> comment to say "Security Module use" instead of "SELinux use".
> > 
> > I really don't know what the status is for user space support on the other
> > LSMs. I couldn't tell you if the searching/reporting are broken or working
> > just fine.
> 
> Understood. And it's only going to get worse with module stacking.
> 
> > Additionally, there is auditctl which has very selinux specific field
> > options to audit on a variety of pieces of the labels. Does this make
> > sense for other LSMs? Do other LSMs have different needs? I really have
> > no idea.
> 
> Three of the record types are SELinux specific. Nine are netlabel, which are
> not SELinux specific, or at least shouldn't be. Three are about setting
> state. We could have different audit records for Smack setting netlabel
> maps from the one SELinux uses, but that seems wrong.

I'd also be open to defining a block for generic messages and a couple small 
blocks (10 or so) for LSM specific events. By defining a new event type, it 
allows you to express the information specific to a LSM without having to 
conform to all other LSMs.


> > But one thing for sure...if we combine them all, I expect patches are
> > needed for user space. By separating them out by event number or some
> > identifier like lsm=, then we can have lsm specific fixups if necessary.
> 
> It seems to me that adding proper support for security modules
> other than SELinux is going to be a project. That's true regardless
> of how the messages are numbered and whether or not we have generic
> messages.

First step would be to either add lsm= to all audit events from LSM's or 
define blocks each will use. It might be best to add the lsm= field if we have 
standard events across all LSMs. Then at some future date we can start using 
that to do something smart with the extra info. But knowing which LSM emitted 
the event is important to cleaning this up.

Also...auditctl issue seems to be glossed over. Do other LSMs have auditing 
needs related to rules + labeling the LSM may do?

-Steve

--
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

Re: Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Monday, December 11, 2017 3:56:35 PM EST Casey Schaufler wrote:
> On 12/11/2017 7:44 AM, Steve Grubb wrote:
> > On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> >>> While it will be potentially painful to switch, the AppArmor project is
> >>> considering to use a unique range in order for audit-userspace to
> >>> support AppArmor audit records. IMHO, SMACK would be free to continue
> >>> using 1400-1499 as long as they don't need audit-userspace support and
> >>> SELinux would continue using 1400-1499.
> >> 
> >> Aside from the comment that says 1400-1499 are for SELinux, and the three
> >> events (1400-1402) that are SELinux specific, the events really are
> >> general. Why not add the AppArmor specifics to the 1400 range? Give them
> >> a generic sounding name and you'll achieve consistency. Change the
> >> comment to say "Security Module use" instead of "SELinux use".
> > 
> > I really don't know what the status is for user space support on the other
> > LSMs. I couldn't tell you if the searching/reporting are broken or working
> > just fine.
> 
> Understood. And it's only going to get worse with module stacking.
> 
> > Additionally, there is auditctl which has very selinux specific field
> > options to audit on a variety of pieces of the labels. Does this make
> > sense for other LSMs? Do other LSMs have different needs? I really have
> > no idea.
> 
> Three of the record types are SELinux specific. Nine are netlabel, which are
> not SELinux specific, or at least shouldn't be. Three are about setting
> state. We could have different audit records for Smack setting netlabel
> maps from the one SELinux uses, but that seems wrong.

I'd also be open to defining a block for generic messages and a couple small 
blocks (10 or so) for LSM specific events. By defining a new event type, it 
allows you to express the information specific to a LSM without having to 
conform to all other LSMs.


> > But one thing for sure...if we combine them all, I expect patches are
> > needed for user space. By separating them out by event number or some
> > identifier like lsm=, then we can have lsm specific fixups if necessary.
> 
> It seems to me that adding proper support for security modules
> other than SELinux is going to be a project. That's true regardless
> of how the messages are numbered and whether or not we have generic
> messages.

First step would be to either add lsm= to all audit events from LSM's or 
define blocks each will use. It might be best to add the lsm= field if we have 
standard events across all LSMs. Then at some future date we can start using 
that to do something smart with the extra info. But knowing which LSM emitted 
the event is important to cleaning this up.

Also...auditctl issue seems to be glossed over. Do other LSMs have auditing 
needs related to rules + labeling the LSM may do?

-Steve

Re: Unique audit record type ranges for individual LSMs

[Laurent Bigonville]

Le 06/12/17 à 18:51, Tyler Hicks a écrit :
> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?
FTR, the apparmor usespace library seems to support the 15xx range for 
quite sometimes already, I see the following commit in the git repository:

commit a6a88a4dd7ec9fd59b01c27f8cd40f653386107b
Author: Steve Beattie <steve@nxnw.org>
Date:   Fri Sep 14 14:00:48 2007 +0000

     This patch adds support to the logparsing library for the type=15xx
     flags when events come through the audit subsystem. It also fixes the
     case where the audit daemon has not been configured with apparmor
     support and the events are reported as type=UNKNOWN[15xx].
     
     It also fixes the testsuite dependencies so that they will get relinked
     when the library changes.

This commits contains the following used id's:

+/* FIXME: this ought to be pulled from <linux/audit.h> but there's no
+ * guarantee these will exist there. */
+#define AUDIT_APPARMOR_AUDIT    1501    /* AppArmor audited grants */
+#define AUDIT_APPARMOR_ALLOWED  1502    /* Allowed Access for learning */
+#define AUDIT_APPARMOR_DENIED   1503
+#define AUDIT_APPARMOR_HINT     1504    /* Process Tracking information */
+#define AUDIT_APPARMOR_STATUS   1505    /* Changes in config */
+#define AUDIT_APPARMOR_ERROR    1506    /* Internal AppArmor Errors */
+

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit