Re: [PATCH ghak124 v3] audit: log nftables configuration change events

[Steve Grubb]

On Thursday, February 11, 2021 11:29:34 AM EST Paul Moore wrote:
> > If I'm not mistaken, iptables emits a single audit log per table, ipset
> > doesn't support audit at all. So I wonder how much audit logging is
> > required at all (for certification or whatever reason). How much
> > granularity is desired?
 
   

> I believe the netfilter auditing was mostly a nice-to-have bit of
> functionality to help add to the completeness of the audit logs, but I
> could very easily be mistaken.  Richard put together those patches, he
> can probably provide the background/motivation for the effort.

There are certifications which levy requirements on information flow control. 
The firewall can decide if information should flow or be blocked. Information 
flow decisions need to be auditable - which we have with the audit target. 
That then swings in requirements on the configuration of the information flow 
policy.

The requirements state a need to audit any management activity - meaning the 
creation, modification, and/or deletion of a "firewall ruleset". Because it 
talks constantly about a ruleset and then individual rules, I suspect only 1 
summary event is needed to say something happened, who did it, and the 
outcome. This would be in line with how selinux is treated: we have 1 summary 
event for loading/modifying/unloading selinux policy.

Hope this helps...

-Steve

Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls

[Steve Grubb]

On Wednesday, October 21, 2020 12:39:26 PM EDT Richard Guy Briggs wrote:
> > I think I have a way to generate a signal to multiple targets in one
> > syscall...  The added challenge is to also give those targets different
> > audit container identifiers.
> 
> Here is an exmple I was able to generate after updating the testsuite
> script to include a signalling example of a nested audit container
> identifier:
> 
> 
> type=PROCTITLE msg=audit(2020-10-21 10:31:16.655:6731) :
> proctitle=/usr/bin/perl -w containerid/test type=CONTAINER_ID
> msg=audit(2020-10-21 10:31:16.655:6731) :
> contid=7129731255799087104^941723245477888 type=OBJ_PID
> msg=audit(2020-10-21 10:31:16.655:6731) : opid=115583 oauid=root ouid=root
> oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> ocomm=perl type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) :
> contid=941723245477888 type=OBJ_PID msg=audit(2020-10-21
> 10:31:16.655:6731) : opid=115580 oauid=root ouid=root oses=1
> obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl
> type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) :
> contid=8098399240850112512^941723245477888 type=OBJ_PID
> msg=audit(2020-10-21 10:31:16.655:6731) : opid=115582 oauid=root ouid=root
> oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> ocomm=perl type=SYSCALL msg=audit(2020-10-21 10:31:16.655:6731) :
> arch=x86_64 syscall=kill success=yes exit=0 a0=0xfffe3c84 a1=SIGTERM
> a2=0x4d524554 a3=0x0 items=0 ppid=115564 pid=115567 auid=root uid=root
> gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
> tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> key=testsuite-1603290671-AcLtUulY 
> 
> There are three CONTAINER_ID records which need some way of associating
> with OBJ_PID records.  An additional CONTAINER_ID record would be present
> if the killing process itself had an audit container identifier.  I think
> the most obvious way to connect them is with a pid= field in the
> CONTAINER_ID record.

pid is the process sending the signal, opid is the process receiving the 
signal. I think you mean opid?

-Steve

Re: [PATCH 2/2] integrity: Add errno field in audit message

[Steve Grubb]

On Wednesday, June 17, 2020 4:44:36 PM EDT Lakshmi Ramasubramanian wrote:
> Error code is not included in the audit messages logged by
> the integrity subsystem. Add "errno" field in the audit messages
> logged by the integrity subsystem and set the value to the error code
> passed to integrity_audit_msg() in the "result" parameter.
> 
> Sample audit messages:
> 
> [6.284329] audit: type=1804 audit(1591756723.627:2): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=kernel op=add_boot_aggregate
> cause=alloc_entry comm="swapper/0" name="boot_aggregate" res=0 errno=-12
> 
> [8.085456] audit: type=1802 audit(1592005947.297:9): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> op=policy_update cause=completed comm="systemd" res=1 errno=0
> 
> Signed-off-by: Lakshmi Ramasubramanian 
> Suggested-by: Steve Grubb 

Acked-by: Steve Grubb 

> ---
>  security/integrity/integrity_audit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/integrity/integrity_audit.c
> b/security/integrity/integrity_audit.c index 5109173839cc..a265024f82f3
> 100644
> --- a/security/integrity/integrity_audit.c
> +++ b/security/integrity/integrity_audit.c
> @@ -53,6 +53,6 @@ void integrity_audit_msg(int audit_msgno, struct inode
> *inode, audit_log_untrustedstring(ab, inode->i_sb->s_id);
>   audit_log_format(ab, " ino=%lu", inode->i_ino);
>   }
> - audit_log_format(ab, " res=%d", !result);
> + audit_log_format(ab, " res=%d errno=%d", !result, result);
>   audit_log_end(ab);
>  }

Re: [PATCH 1/2] integrity: Add errno field in audit message

[Steve Grubb]

On Tuesday, June 16, 2020 3:53:40 PM EDT Mimi Zohar wrote:
> On Tue, 2020-06-16 at 11:55 -0400, Steve Grubb wrote:
> > On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote:
> > > On 6/16/20 8:29 AM, Steve Grubb wrote:
> > > >>>>> The idea is a good idea, but you're assuming that "result" is
> > > >>>>> always errno.  That was probably true originally, but isn't now. 
> > > >>>>> For example, ima_appraise_measurement() calls xattr_verify(),
> > > >>>>> which compares the security.ima hash with the calculated file
> > > >>>>> hash.  On failure, it returns the result of memcmp().  Each and
> > > >>>>> every code path will need to be checked.
> > > >>>> 
> > > >>>> Good catch Mimi.
> > > >>>> 
> > > >>>> Instead of "errno" should we just use "result" and log the value
> > > >>>> given in the result parameter?
> > > >>> 
> > > >>> That would likely collide with another field of the same name which
> > > >>> is the operation's results. If it really is errno, the name is fine.
> > > >>> It's generic enough that it can be reused on other events if that
> > > >>> mattered.
> > > >> 
> > > >> Steve, what is the historical reason why we have both "res" and
> > > >> "result" for indicating a boolean success/fail?  I'm just curious
> > > >> how we ended up this way, and who may still be using "result".
> > > > 
> > > > I think its pam and some other user space things did this. But
> > > > because of mixed machines in datacenters supporting multiple versions
> > > > of OS, we have to leave result alone. It has to be 0,1 or success/
> > > > fail. We cannot use it for errno.
> > > 
> > > As Mimi had pointed out, since the value passed in result parameter is
> > > not always an error code, "errno" is not an appropriate name.
> > > 
> > > Can we add a new field, say, "op_result" to report the result of the
> > > specified operation?
> > 
> > Sure. But since it is errno sometimes, how would we know when to
> > translate it?
> 
> Perhaps the solution is not to imply "res" is "errno", but pass it as
> a separate "errno" field.

That's what is done on syscalls. There is success and exit where they both 
have different meaning sometimes but otherwise they agree.

> Then only include "errno" in the audit message when it isn't zero.  This
> assumes that some audit messages for the same audit number include errno,
> while others do not.

We normally do not like to have fields that swing in and out because then its 
hard to know exactly what's in the event. When an event has different fields 
under special conditions, then we just say call it a new event. Split it into 
2 or 3 instead forcing it all into 1. And we also do not like fields that 
change meaning. Because then intepretation becomes hard. Or other people 
wishing to record the same info in another event have to follow the same 
pattern.

So, if you really need this field, the give some name like err_code or errno 
or anything not taken. And just fill it out every time. Its OK to be 0. If 
this only happens under some special operation, then make it a new event and 
fill it out only for that operation/event.

Best Regards,
-Steve


> With this solution, the existing integrity_audit_msg() could become a
> wrapper for the new function.
> 
> Mimi

Re: [PATCH 1/2] integrity: Add errno field in audit message

[Steve Grubb]

On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote:
> On 6/16/20 8:29 AM, Steve Grubb wrote:
> >>>>> The idea is a good idea, but you're assuming that "result" is always
> >>>>> errno.  That was probably true originally, but isn't now.  For
> >>>>> example, ima_appraise_measurement() calls xattr_verify(), which
> >>>>> compares the security.ima hash with the calculated file hash.  On
> >>>>> failure, it returns the result of memcmp().  Each and every code path
> >>>>> will need to be checked.
> >>>> 
> >>>> Good catch Mimi.
> >>>> 
> >>>> Instead of "errno" should we just use "result" and log the value given
> >>>> in the result parameter?
> >>> 
> >>> That would likely collide with another field of the same name which is
> >>> the
> >>> operation's results. If it really is errno, the name is fine. It's
> >>> generic
> >>> enough that it can be reused on other events if that mattered.
> >> 
> >> Steve, what is the historical reason why we have both "res" and
> >> "result" for indicating a boolean success/fail?  I'm just curious how
> >> we ended up this way, and who may still be using "result".
> > 
> > I think its pam and some other user space things did this. But because of
> > mixed machines in datacenters supporting multiple versions of OS, we have
> > to leave result alone. It has to be 0,1 or success/fail. We cannot use
> > it for errno.
> 
> As Mimi had pointed out, since the value passed in result parameter is
> not always an error code, "errno" is not an appropriate name.
> 
> Can we add a new field, say, "op_result" to report the result of the
> specified operation?

Sure. But since it is errno sometimes, how would we know when to translate 
it?

-Steve

Re: [PATCH v2 1/2] integrity: Add result field in audit message

[Steve Grubb]

On Monday, June 15, 2020 6:51:22 PM EDT Paul Moore wrote:
> On Fri, Jun 12, 2020 at 10:26 PM Lakshmi Ramasubramanian
> 
>  wrote:
> > Result code is not included in the audit messages logged by
> > the integrity subsystem. Add "result" field in the audit messages
> > logged by the integrity subsystem and set the value to the result code
> > passed to integrity_audit_msg() in the "result" parameter.
> > 
> > Sample audit message:
> > 
> > [6.284329] audit: type=1804 audit(1591756723.627:2): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=kernel op=add_boot_aggregate
> > cause=alloc_entry comm="swapper/0" name="boot_aggregate" res=0
> > result=-12
> > 
> > [8.085456] audit: type=1802 audit(1592005947.297:9): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > op=policy_update cause=completed comm="systemd" res=1 result=0
> > 
> > Signed-off-by: Lakshmi Ramasubramanian 
> > Suggested-by: Steve Grubb 
> > ---
> > 
> >  security/integrity/integrity_audit.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> If we can't use "res=" to carry more than 0/1 then this seems reasonable.

Paul,

But we can't do this. The field name dictionary says this is used to convey 
success/fail. It is hard coded in the field interpretation table to look for 
0/1 and interpret that. Interpeting this field will now produce an error 
message. And "result" is a searchable field.

As I suggested a few emails back, let's just use errno or something not 
already taken in the dictionary. NACK.

-Steve

> Acked-by: Paul Moore 
> 
> > diff --git a/security/integrity/integrity_audit.c
> > b/security/integrity/integrity_audit.c index 5109173839cc..84002d3d5a95
> > 100644
> > --- a/security/integrity/integrity_audit.c
> > +++ b/security/integrity/integrity_audit.c
> > @@ -53,6 +53,6 @@ void integrity_audit_msg(int audit_msgno, struct inode
> > *inode,> 
> > audit_log_untrustedstring(ab, inode->i_sb->s_id);
> > audit_log_format(ab, " ino=%lu", inode->i_ino);
> > 
> > }
> > 
> > -   audit_log_format(ab, " res=%d", !result);
> > +   audit_log_format(ab, " res=%d result=%d", !result, result);
> > 
> > audit_log_end(ab);
> >  
> >  }
> > 
> > --
> > 2.27.0

Re: [PATCH 1/2] integrity: Add errno field in audit message

[Steve Grubb]

On Monday, June 15, 2020 6:58:13 PM EDT Paul Moore wrote:
> On Mon, Jun 15, 2020 at 6:23 PM Steve Grubb  wrote:
> > On Friday, June 12, 2020 3:50:14 PM EDT Lakshmi Ramasubramanian wrote:
> > > On 6/12/20 12:25 PM, Mimi Zohar wrote:
> > > > The idea is a good idea, but you're assuming that "result" is always
> > > > errno.  That was probably true originally, but isn't now.  For
> > > > example, ima_appraise_measurement() calls xattr_verify(), which
> > > > compares the security.ima hash with the calculated file hash.  On
> > > > failure, it returns the result of memcmp().  Each and every code path
> > > > will need to be checked.
> > > 
> > > Good catch Mimi.
> > > 
> > > Instead of "errno" should we just use "result" and log the value given
> > > in the result parameter?
> > 
> > That would likely collide with another field of the same name which is
> > the
> > operation's results. If it really is errno, the name is fine. It's
> > generic
> > enough that it can be reused on other events if that mattered.
> 
> Steve, what is the historical reason why we have both "res" and
> "result" for indicating a boolean success/fail?  I'm just curious how
> we ended up this way, and who may still be using "result".

I think its pam and some other user space things did this. But because of 
mixed machines in datacenters supporting multiple versions of OS, we have to 
leave result alone. It has to be 0,1 or success/fail. We cannot use it for 
errno.

-Steve

Re: [PATCH 1/2] integrity: Add errno field in audit message

[Steve Grubb]

On Friday, June 12, 2020 3:50:14 PM EDT Lakshmi Ramasubramanian wrote:
> On 6/12/20 12:25 PM, Mimi Zohar wrote:
> > The idea is a good idea, but you're assuming that "result" is always
> > errno.  That was probably true originally, but isn't now.  For
> > example, ima_appraise_measurement() calls xattr_verify(), which
> > compares the security.ima hash with the calculated file hash.  On
> > failure, it returns the result of memcmp().  Each and every code path
> > will need to be checked.
> 
> Good catch Mimi.
> 
> Instead of "errno" should we just use "result" and log the value given
> in the result parameter?

That would likely collide with another field of the same name which is the 
operation's results. If it really is errno, the name is fine. It's generic 
enough that it can be reused on other events if that mattered.


>  From the audit field dictionary (link given below) "result" is already
> a known field that is used to indicate the result of the audited operation.
> 
> @Steve\Paul:
> Like "res" is "result" also expected to have only values "0" or "1", or
> can it be any result code?

It should only be 0 or 1. Sometime in the past it may have been the words 
success/fail. But we've been converting those as we find them.

-Steve

> https://github.com/linux-audit/audit-documentation/blob/master/specs/fields
> /field-dictionary.csv
> 
> res   alphanumericresult of the audited operation(success/fail)
> 
> resultalphanumericresult of the audited operation(success/fail)

Re: [PATCH v3] IMA: Add audit log for failure conditions

[Steve Grubb]

On Tuesday, June 9, 2020 1:15:55 PM EDT Richard Guy Briggs wrote:
> On 2020-06-09 10:00, Lakshmi Ramasubramanian wrote:
> > On 6/9/20 9:43 AM, Steve Grubb wrote:
> > > > The number in parenthesis is the error code (such as ENOMEM, EINVAL,
> > > > etc.) IMA uses this format for reporting TPM errors in one of the
> > > > audit
> > > > messages (In ima_add_template_entry()). I followed the same pattern.
> > > > 
> > > > Would it be better if the value for "cause" is formatted as
> > > > 
> > > > cause=hashing_error_-22
> > > > 
> > > > cause=alloc_entry_-12
> > > 
> > > Neither fit the name=value style that all other events follow. What
> > > would fit the style is something like this:
> > > 
> > > cause=hashing_error  errno=-22
> > > cause=alloc_entry errno=-12
> > > 
> > > Would this be OK? Also, errno is only to illustrate. You can name it
> > > something else as long as there are no use case collisions with our
> > > dictionary of field names.
> > > 
> > > https://github.com/linux-audit/audit-documentation/blob/master/specs/fi
> > > elds/ field-dictionary.csv
> > 
> > I am fine with this.

Thanks, this makes interpreting it a couple lines of code.

> > "errno" is currently not listed in the dictionary of audit message field
> > names (Thanks for the pointer to this one Steve)

It can be easily added.

> > Mimi - please let me know if you have any concerns with adding the
> > "result" code in "errno" field in integrity_audit_msg().
> 
> If it is added, it should be appended to the end of the record since it
> is an existing record format, then in the case of res=1, errno= should
> still be present (not swing in and out) and just contain zero.  (Or
> another value if there is a non-fatal warning?)

This is not a searchable field, so it can go anywhere. If it is searchable, 
ausearch expects ordering of other searchable fields.

-Steve

Re: [PATCH v3] IMA: Add audit log for failure conditions

[Steve Grubb]

Hello,

On Tuesday, June 9, 2020 11:58:02 AM EDT Lakshmi Ramasubramanian wrote:
> On 6/9/20 8:40 AM, Steve Grubb wrote:
> > On Monday, June 8, 2020 5:53:43 PM EDT Lakshmi Ramasubramanian wrote:
> >> The final log statement in process_buffer_measurement() for failure
> >> condition is at debug level. This does not log the message unless
> >> the system log level is raised which would significantly increase
> >> the messages in the system log. Change this log message to an audit
> >> message for better triaging failures in the function.
> >> 
> >> ima_alloc_key_entry() does not log a message for failure condition.
> >> Add an audit message for failure condition in this function.
> > 
> >> Sample audit messages:
> > Wouldn't it be better to have an IMA_ERROR record type?
> 
> type "1804" is AUDIT_INTEGRITY_PCR which is used for failures to add to
> the measurement list.
> 
> >> [8.051937] audit: type=1804 audit(1591633422.365:8): pid=1 uid=0
> >> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> >> op=measuring_keys cause=hashing_error(-22)
> > 
> > The audit system uses a name=value scheme to express information. This
> > last field has something in parenthesis that may need to be interpreted.
> > In its current form, we can't do this. It would require writing code to
> > special case this event, go to this field, find the first parenthesis,
> > find the second, extract what's between, and look it up.
> > 
> > It would be better if that number in parenthesis was normalized to the
> > expected way we do audit events so nothing special has to be made.
> 
> The number in parenthesis is the error code (such as ENOMEM, EINVAL,
> etc.) IMA uses this format for reporting TPM errors in one of the audit
> messages (In ima_add_template_entry()). I followed the same pattern.
> 
> Would it be better if the value for "cause" is formatted as
> 
> cause=hashing_error_-22
> 
> cause=alloc_entry_-12

Neither fit the name=value style that all other events follow. What would fit 
the style is something like this:

cause=hashing_error  errno=-22
 
cause=alloc_entry errno=-12

Would this be OK? Also, errno is only to illustrate. You can name it 
something else as long as there are no use case collisions with our 
dictionary of field names.

https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/
field-dictionary.csv

-Steve

Re: [PATCH v3] IMA: Add audit log for failure conditions

[Steve Grubb]

On Monday, June 8, 2020 5:53:43 PM EDT Lakshmi Ramasubramanian wrote:
> The final log statement in process_buffer_measurement() for failure
> condition is at debug level. This does not log the message unless
> the system log level is raised which would significantly increase
> the messages in the system log. Change this log message to an audit
> message for better triaging failures in the function.
> 
> ima_alloc_key_entry() does not log a message for failure condition.
> Add an audit message for failure condition in this function.
> 
> Sample audit messages:

Wouldn't it be better to have an IMA_ERROR record type?

> [8.051937] audit: type=1804 audit(1591633422.365:8): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> op=measuring_keys cause=hashing_error(-22) 

The audit system uses a name=value scheme to express information. This last 
field has something in parenthesis that may need to be interpreted. In its 
current form, we can't do this. It would require writing code to special case 
this event, go to this field, find the first parenthesis, find the second, 
extract what's between, and look it up.

It would be better if that number in parenthesis was normalized to the 
expected way we do audit events so nothing special has to be made.

-Steve


> comm="systemd"
> name=".builtin_trusted_keys" res=0
> 
> [8.063218] audit: type=1804 audit(1591633422.377:9): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> op=measuring_kexec_cmdline cause=alloc_entry(-12) comm="systemd"
> name="kexec-cmdline" res=0
> 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  security/integrity/ima/ima.h|  2 ++
>  security/integrity/ima/ima_main.c   | 37 +
>  security/integrity/ima/ima_queue.c  |  2 --
>  security/integrity/ima/ima_queue_keys.c |  4 +++
>  4 files changed, 37 insertions(+), 8 deletions(-)
> 
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index df93ac258e01..8a47249c6238 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -47,6 +47,8 @@ enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8 };
> 
>  #define NR_BANKS(chip) ((chip != NULL) ? chip->nr_allocated_banks : 0)
> 
> +#define AUDIT_CAUSE_LEN_MAX 32
> +
>  /* current content of the policy */
>  extern int ima_policy_flag;
> 
> diff --git a/security/integrity/ima/ima_main.c
> b/security/integrity/ima/ima_main.c index 800fb3bba418..b10f09bc7eca
> 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -739,6 +739,9 @@ void process_buffer_measurement(const void *buf, int
> size, int pcr, const char *keyring)
>  {
>   int ret = 0;
> + const char *audit_cause = "ENOMEM";
> + const char *op = "measuring_keys";
> + char measurement_audit_cause[AUDIT_CAUSE_LEN_MAX];
>   struct ima_template_entry *entry = NULL;
>   struct integrity_iint_cache iint = {};
>   struct ima_event_data event_data = {.iint = ,
> @@ -793,21 +796,43 @@ void process_buffer_measurement(const void *buf, int
> size, iint.ima_hash->length = hash_digest_size[ima_hash_algo];
> 
>   ret = ima_calc_buffer_hash(buf, size, iint.ima_hash);
> - if (ret < 0)
> + if (ret < 0) {
> + audit_cause = "hashing_error";
>   goto out;
> + }
> 
>   ret = ima_alloc_init_template(_data, , template);
> - if (ret < 0)
> + if (ret < 0) {
> + audit_cause = "alloc_entry";
>   goto out;
> + }
> 
>   ret = ima_store_template(entry, violation, NULL, buf, pcr);
> -
> - if (ret < 0)
> + if (ret < 0) {
> + audit_cause = "store_entry";
>   ima_free_template_entry(entry);
> + }
> 
>  out:
> - if (ret < 0)
> - pr_devel("%s: failed, result: %d\n", __func__, ret);
> + if (ret < 0) {
> + snprintf(measurement_audit_cause, AUDIT_CAUSE_LEN_MAX,
> +  "%s(%d)", audit_cause, ret);
> +
> + switch (func) {
> + case KEXEC_CMDLINE:
> + op = "measuring_kexec_cmdline";
> + break;
> + case KEY_CHECK:
> + op = "measuring_keys";
> + break;
> + default:
> + op = "measuring_blacklisted_hash";
> + break;
> + }
> +
> + integrity_audit_msg(AUDIT_INTEGRITY_PCR, NULL, eventname,
> + op, measurement_audit_cause, ret, 0);
> + }
> 
>   return;
>  }
> diff --git a/security/integrity/ima/ima_queue.c
> b/security/integrity/ima/ima_queue.c index fb4ec270f620..4a761d765c6c
> 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -19,8 +19,6 @@
>  #include 
>  #include "ima.h"
> 
> -#define AUDIT_CAUSE_LEN_MAX 32
> -
>  /* pre-allocated array of tpm_digest structures to extend a PCR */
>  static 

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

[Steve Grubb]

On Thursday, June 4, 2020 1:57:56 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 468a23390457..3a9100e95fda 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -75,6 +75,7 @@
> > > #include 
> > > #include 
> > > #include 
> > > +#include 
> > > 
> > > #include "audit.h"
> > > 
> > > @@ -136,9 +137,26 @@ struct audit_nfcfgop_tab {
> > > };
> > > 
> > > static const struct audit_nfcfgop_tab audit_nfcfgs[] = {
> > > -   { AUDIT_XT_OP_REGISTER, "register"  },
> > > -   { AUDIT_XT_OP_REPLACE,  "replace"   },
> > > -   { AUDIT_XT_OP_UNREGISTER,   "unregister"},
> > > +   { AUDIT_XT_OP_REGISTER, "xt_register"
> > 
> > },
> > 
> > > +   { AUDIT_XT_OP_REPLACE,  "xt_replace"   
> > >}, +   { AUDIT_XT_OP_UNREGISTER,   "xt_unregister" 
> > >   }, +   { AUDIT_NFT_OP_TABLE_REGISTER, 
> > > "nft_register_table"> 
> > },
> > 
> > > +   { AUDIT_NFT_OP_TABLE_UNREGISTER,"nft_unregister_table" 
> > >}, +   { AUDIT_NFT_OP_CHAIN_REGISTER, 
> > > "nft_register_chain"> 
> > },
> > 
> > > +   { AUDIT_NFT_OP_CHAIN_UNREGISTER,"nft_unregister_chain" 
> > >}, +   { AUDIT_NFT_OP_RULE_REGISTER,  
> > > "nft_register_rule"> 
> > },
> > 
> > > +   { AUDIT_NFT_OP_RULE_UNREGISTER, "nft_unregister_rule"
> > 
> > },
> > 
> > > +   { AUDIT_NFT_OP_SET_REGISTER,"nft_register_set"
> > 
> > },
> > 
> > > +   { AUDIT_NFT_OP_SET_UNREGISTER,  "nft_unregister_set"
> > 
> > },
> > 
> > > +   { AUDIT_NFT_OP_SETELEM_REGISTER,"nft_register_setelem" 
> > >}, +   { AUDIT_NFT_OP_SETELEM_UNREGISTER, 
> > > "nft_unregister_setelem"   }, +   { AUDIT_NFT_OP_GEN_REGISTER,
> > >"nft_register_gen" }, +   {
> > > AUDIT_NFT_OP_OBJ_REGISTER,"nft_register_obj" }, + 
> > >  { AUDIT_NFT_OP_OBJ_UNREGISTER,  "nft_unregister_obj" 
> > >  }, +   { AUDIT_NFT_OP_OBJ_RESET,   "nft_reset_obj"   
> > > }, +   { AUDIT_NFT_OP_FLOWTABLE_REGISTER, 
> > > "nft_register_flowtable"   }, +   {
> > > AUDIT_NFT_OP_FLOWTABLE_UNREGISTER,"nft_unregister_flowtable" }, + 
> > >  { AUDIT_NFT_OP_INVALID, "nft_invalid"
> > 
> > },
> > 
> > > };
> > 
> > I still don't like the event format because it doesn't give complete
> > subject information. However, I thought I'd comment on this string
> > table. Usually it's sufficient to log the number and then have the
> > string table in user space which looks it up during interpretation.
> 
> That is a good idea that would help reduce kernel cycles and netlink
> bandwidth, but the format was set in 2011 so it is a bit late to change
> that now:
> fbabf31e4d48 ("netfilter: create audit records for x_tables
> replaces")

Nothing searches/interprets that field name. So, you can redefine it by 
renaming it. Or just go with what you have. My preference is push that to 
user space. But not a showstopper "as is".

-Steve

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

[Steve Grubb]

On Thursday, June 4, 2020 9:20:49 AM EDT Richard Guy Briggs wrote:
> iptables, ip6tables, arptables and ebtables table registration,
> replacement and unregistration configuration events are logged for the
> native (legacy) iptables setsockopt api, but not for the
> nftables netlink api which is used by the nft-variant of iptables in
> addition to nftables itself.
> 
> Add calls to log the configuration actions in the nftables netlink api.
> 
> This uses the same NETFILTER_CFG record format but overloads the table
> field.
> 
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) : table=?:0;?:0
> family=unspecified entries=2 op=nft_register_gen pid=396
> subj=system_u:system_r:firewalld_t:s0 comm=firewalld ...
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) :
> table=firewalld:1;?:0 family=inet entries=0 op=nft_register_table pid=396
> subj=system_u:system_r:firewalld_t:s0 comm=firewalld ...
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) :
> table=firewalld:1;filter_FORWARD:85 family=inet entries=8
> op=nft_register_chain pid=396 subj=system_u:system_r:firewalld_t:s0
> comm=firewalld ...
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) :
> table=firewalld:1;filter_FORWARD:85 family=inet entries=101
> op=nft_register_rule pid=396 subj=system_u:system_r:firewalld_t:s0
> comm=firewalld ...
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) :
> table=firewalld:1;__set0:87 family=inet entries=87 op=nft_register_setelem
> pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld ...
>   type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) :
> table=firewalld:1;__set0:87 family=inet entries=0 op=nft_register_set
> pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
> 
> For further information please see issue
> https://github.com/linux-audit/audit-kernel/issues/124
> 
> Signed-off-by: Richard Guy Briggs 
> ---
> Changelog:
> v3:
> - inline message type rather than table
> 
> v2:
> - differentiate between xtables and nftables
> - add set, setelem, obj, flowtable, gen
> - use nentries field as appropriate per type
> - overload the "tables" field with table handle and chain/set/flowtable
> 
>  include/linux/audit.h |  18 
>  kernel/auditsc.c  |  24 --
>  net/netfilter/nf_tables_api.c | 103
> ++ 3 files changed, 142
> insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 3fcd9ee49734..604ede630580 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -98,6 +99,23 @@ enum audit_nfcfgop {
>   AUDIT_XT_OP_REGISTER,
>   AUDIT_XT_OP_REPLACE,
>   AUDIT_XT_OP_UNREGISTER,
> + AUDIT_NFT_OP_TABLE_REGISTER,
> + AUDIT_NFT_OP_TABLE_UNREGISTER,
> + AUDIT_NFT_OP_CHAIN_REGISTER,
> + AUDIT_NFT_OP_CHAIN_UNREGISTER,
> + AUDIT_NFT_OP_RULE_REGISTER,
> + AUDIT_NFT_OP_RULE_UNREGISTER,
> + AUDIT_NFT_OP_SET_REGISTER,
> + AUDIT_NFT_OP_SET_UNREGISTER,
> + AUDIT_NFT_OP_SETELEM_REGISTER,
> + AUDIT_NFT_OP_SETELEM_UNREGISTER,
> + AUDIT_NFT_OP_GEN_REGISTER,
> + AUDIT_NFT_OP_OBJ_REGISTER,
> + AUDIT_NFT_OP_OBJ_UNREGISTER,
> + AUDIT_NFT_OP_OBJ_RESET,
> + AUDIT_NFT_OP_FLOWTABLE_REGISTER,
> + AUDIT_NFT_OP_FLOWTABLE_UNREGISTER,
> + AUDIT_NFT_OP_INVALID,
>  };
> 
>  extern int is_audit_feature_set(int which);
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 468a23390457..3a9100e95fda 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -75,6 +75,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "audit.h"
> 
> @@ -136,9 +137,26 @@ struct audit_nfcfgop_tab {
>  };
> 
>  static const struct audit_nfcfgop_tab audit_nfcfgs[] = {
> - { AUDIT_XT_OP_REGISTER, "register"  },
> - { AUDIT_XT_OP_REPLACE,  "replace"   },
> - { AUDIT_XT_OP_UNREGISTER,   "unregister"},
> + { AUDIT_XT_OP_REGISTER, "xt_register"  
},
> + { AUDIT_XT_OP_REPLACE,  "xt_replace"   },
> + { AUDIT_XT_OP_UNREGISTER,   "xt_unregister"},
> + { AUDIT_NFT_OP_TABLE_REGISTER,  "nft_register_table"   
},
> + { AUDIT_NFT_OP_TABLE_UNREGISTER,"nft_unregister_table" },
> + { AUDIT_NFT_OP_CHAIN_REGISTER,  "nft_register_chain"   
},
> + { AUDIT_NFT_OP_CHAIN_UNREGISTER,"nft_unregister_chain" },
> + { AUDIT_NFT_OP_RULE_REGISTER,   "nft_register_rule"
},
> + { AUDIT_NFT_OP_RULE_UNREGISTER, "nft_unregister_rule"  
},
> + { AUDIT_NFT_OP_SET_REGISTER,"nft_register_set" 
},
> + { AUDIT_NFT_OP_SET_UNREGISTER,  "nft_unregister_set"   
},
> + { 

Re: [PATCH ghak25 v6] audit: add subj creds to NETFILTER_CFG record to cover async unregister

[Steve Grubb]

On Wednesday, May 20, 2020 2:40:45 PM EDT Paul Moore wrote:
> On Wed, May 20, 2020 at 12:55 PM Richard Guy Briggs  wrote:
> > On 2020-05-20 12:51, Richard Guy Briggs wrote:
> > > Some table unregister actions seem to be initiated by the kernel to
> > > garbage collect unused tables that are not initiated by any userspace
> > > actions.  It was found to be necessary to add the subject credentials
> > > to cover this case to reveal the source of these actions.  A sample
> > > record:
> > > 
> > > The uid, auid, tty, ses and exe fields have not been included since
> > > they
> > > are in the SYSCALL record and contain nothing useful in the non-user
> > > context.
> > > 
> > >   type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat
> > >   family=bridge entries=0 op=unregister pid=153
> > >   subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2
>
> FWIW, that record looks good.

It's severely broken

cat log.file
type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat 
family=bridge entries=0 op=unregister pid=153 
subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2

ausearch -if log.file --format text
At 19:33:40 12/31/1969  did-unknown 

ausearch -if log.file --format csv
NODE,EVENT,DATE,TIME,SERIAL_NUM,EVENT_KIND,SESSION,SUBJ_PRIME,SUBJ_SEC,SUBJ_KIND,ACTION,RESULT,OBJ_PRIME,OBJ_SEC,OBJ_KIND,HOW
error normalizing NETFILTER_CFG
,NETFILTER_CFG,12/31/1969,19:33:40,0,,

This is unusable. This is why the bug was filed in the first place.

-Steve

> > > Signed-off-by: Richard Guy Briggs 
> > 
> > Self-NACK.  I forgot to remove cred and tty declarations.

Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister

[Steve Grubb]

On Wednesday, May 6, 2020 6:42:33 PM EDT Richard Guy Briggs wrote:
> > > > We can't be adding deleting fields based on how its triggered. If
> > > > they are unset, that is fine. The main issue is they have to behave
> > > > the same.
> > > 
> > > I don't think the intent was to have fields swing in and out depending
> > > on trigger.  The idea is to potentially permanently not include them in
> > > this record type only.  The justification is that where they aren't
> > > needed for the kernel trigger situation it made sense to delete them
> > > because if it is a user context event it will be accompanied by a
> > > syscall record that already has that information and there would be no
> > > sense in duplicating it.
> > 
> > We should not be adding syscall records to anything that does not result
> > from a syscall rule triggering the event. Its very wasteful. More
> > wasteful than just adding the necessary fields.
> 
> So what you are saying is you want all the fields that are being
> proposed to be added to this record?

Yes.

> If the records are all from one event, they all should all have the same
> timestamp/serial number so that the records are kept together and not
> mistaken for multiple events.

But NETFILTER_CFG is a simple event known to have only 1 record.

> One reason for having information in seperate records is to be able to
> filter them either in kernel or in userspace if you don't need certain
> records.

We can't filter out SYSCALL.

-Steve

Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister

[Steve Grubb]

On Wednesday, April 29, 2020 5:32:47 PM EDT Richard Guy Briggs wrote:
> On 2020-04-29 14:47, Steve Grubb wrote:
> > On Wednesday, April 29, 2020 10:31:46 AM EDT Richard Guy Briggs wrote:
> > > On 2020-04-28 18:25, Paul Moore wrote:
> > > > On Wed, Apr 22, 2020 at 5:40 PM Richard Guy Briggs 
> > 
> > wrote:
> > > > > Some table unregister actions seem to be initiated by the kernel to
> > > > > garbage collect unused tables that are not initiated by any
> > > > > userspace
> > > > > actions.  It was found to be necessary to add the subject
> > > > > credentials
> > > > > to  cover this case to reveal the source of these actions.  A
> > > > > sample
> > > > > record:
> > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) :
> > > > > table=nat
> > > > > family=bridge entries=0 op=unregister pid=153 uid=root auid=unset
> > > > > tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0
> > > > > comm=kworker/u4:2 exe=(null)>
> > > > 
> > > > [I'm going to comment up here instead of in the code because it is a
> > > > bit easier for everyone to see what the actual impact might be on the
> > > > records.]
> > > > 
> > > > Steve wants subject info in this case, okay, but let's try to trim
> > > > out
> > > > some of the fields which simply don't make sense in this record; I'm
> > > > thinking of fields that are unset/empty in the kernel case and are
> > > > duplicates of other records in the userspace/syscall case.  I think
> > > > that means we can drop "tty", "ses", "comm", and "exe" ... yes?
> > > 
> > > From the ghak28 discussion, this list and order was selected due to
> > > Steve's preference for the "kernel" record convention, so deviating
> > > from this will create yet a new field list.  I'll defer to Steve on
> > > this. It also has to do with the searchability of fields if they are
> > > missing.
> > > 
> > > I do agree that some fields will be superfluous in the kernel case.
> > > The most important field would be "subj", but then "pid" and "comm", I
> > > would think.  Based on this contents of the "subj" field, I'd think
> > > that "uid", "auid", "tty", "ses" and "exe" are not needed.
> > 
> > We can't be adding deleting fields based on how its triggered. If they
> > are unset, that is fine. The main issue is they have to behave the same.
> 
> I don't think the intent was to have fields swing in and out depending
> on trigger.  The idea is to potentially permanently not include them in
> this record type only.  The justification is that where they aren't
> needed for the kernel trigger situation it made sense to delete them
> because if it is a user context event it will be accompanied by a
> syscall record that already has that information and there would be no
> sense in duplicating it.

We should not be adding syscall records to anything that does not result from 
a syscall rule triggering the event. Its very wasteful. More wasteful than 
just adding the necessary fields.

I also wished we had a coding specification that put this in writing so that 
every event is not a committee decision. That anyone can look at the document 
and Do The Right Thing ™.

If I add a section to Writing-Good-Events outlining the expected ordering of 
fields, would that be enough that we do not have long discussions about event 
format? I'm thinking this would also help new people that want to contribute.

-Steve

Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister

[Steve Grubb]

On Wednesday, April 29, 2020 10:31:46 AM EDT Richard Guy Briggs wrote:
> On 2020-04-28 18:25, Paul Moore wrote:
> > On Wed, Apr 22, 2020 at 5:40 PM Richard Guy Briggs  
wrote:
> > > Some table unregister actions seem to be initiated by the kernel to
> > > garbage collect unused tables that are not initiated by any userspace
> > > actions.  It was found to be necessary to add the subject credentials
> > > to  cover this case to reveal the source of these actions.  A sample
> > > record:
> > >   type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat
> > >   family=bridge entries=0 op=unregister pid=153 uid=root auid=unset
> > >   tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0
> > >   comm=kworker/u4:2 exe=(null)> 
> > [I'm going to comment up here instead of in the code because it is a
> > bit easier for everyone to see what the actual impact might be on the
> > records.]
> > 
> > Steve wants subject info in this case, okay, but let's try to trim out
> > some of the fields which simply don't make sense in this record; I'm
> > thinking of fields that are unset/empty in the kernel case and are
> > duplicates of other records in the userspace/syscall case.  I think
> > that means we can drop "tty", "ses", "comm", and "exe" ... yes?
> 
> From the ghak28 discussion, this list and order was selected due to
> Steve's preference for the "kernel" record convention, so deviating from
> this will create yet a new field list.  I'll defer to Steve on this.  It
> also has to do with the searchability of fields if they are missing.
> 
> I do agree that some fields will be superfluous in the kernel case.
> The most important field would be "subj", but then "pid" and "comm", I
> would think.  Based on this contents of the "subj" field, I'd think that
> "uid", "auid", "tty", "ses" and "exe" are not needed.

We can't be adding deleting fields based on how its triggered. If they are 
unset, that is fine. The main issue is they have to behave the same.

> > While "auid" is a potential target for removal based on the
> > dup-or-unset criteria, I think it falls under Steve's request for
> > subject info here, even if it is garbage in this case.

auid is always unset for daemons. We do not throw it away because of that.

-Steve

> If we keep auid, I'd say keep ses, since they usually go together,
> though they are separated by another field in this "kernel" record field
> ordering.
> 
> I expect this orphan record to occur so infrequently that I don't think
> bandwidth or space are a serious concern.
> 
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > 
> > >  kernel/auditsc.c | 18 ++
> > >  1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index d281c18d1771..d7a45b181be0 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -2557,12 +2557,30 @@ void __audit_log_nfcfg(const char *name, u8 af,
> > > unsigned int nentries,> > 
> > >enum audit_nfcfgop op)
> > >  
> > >  {
> > >  
> > > struct audit_buffer *ab;
> > > 
> > > +   const struct cred *cred;
> > > +   struct tty_struct *tty;
> > > +   char comm[sizeof(current->comm)];
> > > 
> > > ab = audit_log_start(audit_context(), GFP_KERNEL,
> > > AUDIT_NETFILTER_CFG);
> > > if (!ab)
> > > 
> > > return;
> > > 
> > > audit_log_format(ab, "table=%s family=%u entries=%u op=%s",
> > > 
> > >  name, af, nentries, audit_nfcfgs[op].s);
> > > 
> > > +
> > > +   cred = current_cred();
> > > +   tty = audit_get_tty();
> > > +   audit_log_format(ab, " pid=%u uid=%u auid=%u tty=%s ses=%u",
> > > +task_pid_nr(current),
> > > +from_kuid(_user_ns, cred->uid),
> > > +from_kuid(_user_ns,
> > > audit_get_loginuid(current)), +tty ?
> > > tty_name(tty) : "(none)",
> > > +audit_get_sessionid(current));
> > > +   audit_put_tty(tty);
> > > +   audit_log_task_context(ab); /* subj= */
> > > +   audit_log_format(ab, " comm=");
> > > +   audit_log_untrustedstring(ab, get_task_comm(comm, current));
> > > +   audit_log_d_path_exe(ab, current->mm); /* exe= */
> > > +
> > > 
> > > audit_log_end(ab);
> > >  
> > >  }
> > >  EXPORT_SYMBOL_GPL(__audit_log_nfcfg);
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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

Re: [PATCH v2 0/5] Add support for O_MAYEXEC

[Steve Grubb]

On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> * Steve Grubb:
> > Now with LD_AUDIT
> > $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> > 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)   = 4
> > 
> > No O_CLOEXEC flag.
> 
> I think you need to explain in detail why you consider this a problem.

Because you can strip the O_MAYEXEC flag from being passed into the kernel. 
Once you do that, you defeat the security mechanism because it never gets 
invoked. The issue is that the only thing that knows _why_ something is being 
opened is user space. With this mechanism, you can attempt to pass this 
reason to the kernel so that it may see if policy permits this. But you can 
just remove the flag.

-Steve

> With LD_PRELOAD and LD_AUDIT, you can already do anything, including
> scanning other loaded objects for a system call instruction and jumping
> to that (in case a security module in the kernel performs a PC check to
> confer additional privileges).
> 
> Thanks,
> Florian

Re: [PATCH v2 0/5] Add support for O_MAYEXEC

[Steve Grubb]

On Friday, September 6, 2019 11:24:50 AM EDT Mickaël Salaün wrote:
> The goal of this patch series is to control script interpretation.  A
> new O_MAYEXEC flag used by sys_open() is added to enable userspace
> script interpreter to delegate to the kernel (and thus the system
> security policy) the permission to interpret/execute scripts or other
> files containing what can be seen as commands.

The problem is that this is only a gentleman's handshake. If I don't tell the
kernel that what I'm opening is tantamount to executing it, then the security
feature is never invoked. It is simple to strip the flags off of any system
call without needing privileges. For example:

#define _GNU_SOURCE
#include 
#include 
#include 

unsigned int
la_version(unsigned int version)
{
return version;
}

unsigned int
la_objopen(struct link_map *map, Lmid_t lmid, uintptr_t *cookie)
{
return LA_FLG_BINDTO | LA_FLG_BINDFROM;
}

typedef int (*openat_t) (int dirfd, const char *pathname, int flags, mode_t 
mode);
static openat_t real_openat = 0L;
int my_openat(int dirfd, const char *pathname, int flags, mode_t mode)
{
flags &= ~O_CLOEXEC;
return real_openat(dirfd, pathname, flags, mode);
}

uintptr_t
la_symbind64(Elf64_Sym *sym, unsigned int ndx, uintptr_t *refcook,
uintptr_t *defcook, unsigned int *flags, const char *symname)
{
if (real_openat == 0L && strcmp(symname, "openat") == 0) {
real_openat = (openat_t) sym->st_value;
return (uintptr_t) my_openat;
}
return sym->st_value;
}

gcc -c -g -Wno-unused-parameter -W -Wall -Wundef -O2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fPIC  test.c
gcc -o strip-flags.so.0 -shared -Wl,-soname,strip-flags.so.0 -ldl test.o

Now, let's make a test program:

#include 
#include 
#include 
#include 

int main(void)
{
int dir_fd, fd;
DIR *d = opendir("/etc");
dir_fd = dirfd(d);
fd = openat(dir_fd, "passwd", O_RDONLY|O_CLOEXEC);
close (fd);
closedir(d);
return 0;
}

gcc -g -W -Wall -Wundef test.c -o test

OK, let's see what happens.
$ strace ./test 2>&1 | grep passwd
openat(3, "passwd", O_RDONLY|O_CLOEXEC) = 4

Now with LD_AUDIT
$ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | 
grep passwd
openat(3, "passwd", O_RDONLY)   = 4

No O_CLOEXEC flag.

-Steve

Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[Steve Grubb]

On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote:
> * Steve Grubb:
> > This flag that is being proposed means that you would have to patch all
> > interpreters to use it. If you are sure that upstreams will accept that,
> > why not just change the policy to interpreters shouldn't execute
> > anything unless the execute bit is set? That is simpler and doesn't need
> > a kernel change. And setting the execute bit is an auditable event.
> 
> I think we need something like O_MAYEXEC so that security policies can
> be enforced and noexec mounts can be detected.

Application whitelisting can already today stop unknown software without 
needing O_MAYEXEC.

> I don't think it's a good idea to do this in userspace, especially the
> latter.

The problem is that passing O_MAYEXEC is opt-in. You can use ptrace/seccomp/
bpf/LD_PRELOAD/LD_AUDIT to remove that bit from an otherwise normal program. 
This does not require privs to do so.

But let's consider that this comes to pass and every interpreter is updated 
and IMA can see the O_MAYEXEC flag. Attackers now simply pivot to running 
programs via stdin. It never touches disk and therefore nothing enforces 
security policy. This already is among the most common ways that malware runs 
today to evade detection.

-Steve

Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[Steve Grubb]

Hello,

On Wednesday, December 12, 2018 9:43:06 AM EDT Jan Kara wrote:
> On Wed 12-12-18 09:17:08, Mickaël Salaün wrote:
> > When the O_MAYEXEC flag is passed, sys_open() may be subject to
> > additional restrictions depending on a security policy implemented by an
> > LSM through the inode_permission hook.
> > 
> > The underlying idea is to be able to restrict scripts interpretation
> > according to a policy defined by the system administrator.  For this to
> > be possible, script interpreters must use the O_MAYEXEC flag
> > appropriately.  To be fully effective, these interpreters also need to
> > handle the other ways to execute code (for which the kernel can't help):
> > command line parameters (e.g., option -e for Perl), module loading
> > (e.g., option -m for Python), stdin, file sourcing, environment
> > variables, configuration files...  According to the threat model, it may
> > be acceptable to allow some script interpreters (e.g. Bash) to interpret
> > commands from stdin, may it be a TTY or a pipe, because it may not be
> > enough to (directly) perform syscalls.
> > 
> > A simple security policy implementation is available in a following
> > patch for Yama.
> > 
> > This is an updated subset of the patch initially written by Vincent
> > Strubel for CLIP OS:
> > https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d
> > 6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch This patch has
> > been used for more than 10 years with customized script interpreters. 
> > Some examples can be found here:
> > https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYE
> > XEC
> > 
> > Signed-off-by: Mickaël Salaün 
> > Signed-off-by: Thibaut Sautereau 
> > Signed-off-by: Vincent Strubel 
> > Reviewed-by: Philippe Trébuchet 
> > Cc: Al Viro 
> > Cc: Kees Cook 
> > Cc: Mickaël Salaün 
> 
> ...
> 
> > diff --git a/fs/open.c b/fs/open.c
> > index 0285ce7dbd51..75479b79a58f 100644
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags,
> > umode_t mode, struct open_flags *o> 
> > if (flags & O_APPEND)
> > 
> > acc_mode |= MAY_APPEND;
> > 
> > +   /* Check execution permissions on open. */
> > +   if (flags & O_MAYEXEC)
> > +   acc_mode |= MAY_OPENEXEC;
> > +
> > 
> > op->acc_mode = acc_mode;
> > 
> > op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
> 
> I don't feel experienced enough in security to tell whether we want this
> functionality or not. But if we do this, shouldn't we also set FMODE_EXEC
> on the resulting struct file? That way also security_file_open() can be
> used to arbitrate such executable opens and in particular
> fanotify permission event FAN_OPEN_EXEC will get properly generated which I
> guess is desirable (support for it is sitting in my tree waiting for the
> merge window) - adding some audit people involved in FAN_OPEN_EXEC to CC.
> Just an idea...

Late in replying. But I think it's important to have a deep look into the 
issue.

TL;DR - This is a gentle man's handshake. It won't _really_ solve the 
problem.

This flag that is being proposed means that you would have to patch all 
interpreters to use it. If you are sure that upstreams will accept that, why 
not just change the policy to interpreters shouldn't execute anything unless 
the execute bit is set? That is simpler and doesn't need a kernel change. And 
setting the execute bit is an auditable event.

The bottom line is that any interpreter has to become a security policy 
enforcement point whether by indicating it wants to execute by setting a flag 
or by refusing to use a file without execute bit set. But this just moves the 
problem to one that is harder to fix. Why in the world does any programming 
language allow programs to be loaded via stdin? 

It is possible to wget a program and pipe it into python which subsequently 
pulls down an ELF shared object and runs it all without touching disk via 
memfd_create (e.g. SnakeEater). This is all direct to memory execution. And 
direct to memory bypasses anti-virus, selinux, IMA, application whitelisting, 
and other integrity schemes.

So, to fix this problem, you really need to not allow any programs to load via 
stdin so that everything that executes has to touch disk. This way you can 
get a fanotify event and see the application and vote yes/no on allowing it. 
And this will be particularly harder with the memfd_create fix for the runc 
container breakout. Prior to that, there were very few uses of that system 
call. Now it may be very common which means finding malicious use just got 
harder to spot.

But assuming these problems got fixed, then we have yet another place to look. 
Many interpreters allow you to specify a command to run via arguments. Some 
have a small buffer and some allow lengthy programs to be entered as an 
argument. One strategy might be that an attacker can bootstrap a lengthier 
program across the network. Python for 

Re: [RFC PATCH ghak10 v6 2/2] ntp: Audit NTP parameters adjustment

[Steve Grubb]

On Thursday, March 7, 2019 7:32:54 AM EST Ondrej Mosnacek wrote:
> Emit an audit record every time selected NTP parameters are modified
> from userspace (via adjtimex(2) or clock_adjtime(2)).
> 
> Such events will now generate records of type AUDIT_TIME_ADJNTPVAL
> containing the following fields:
>   - op -- which value was adjusted:
> - offset -- corresponding to the time_offset variable
> - freq   -- corresponding to the time_freq variable
> - status -- corresponding to the time_status variable
> - adjust -- corresponding to the time_adjust variable
> - tick   -- corresponding to the tick_usec variable
> - tai-- corresponding to the timekeeping's TAI offset
>   - old -- the old value
>   - new -- the new value
> 
> For reference, running the following commands:
> 
> auditctl -D
> auditctl -a exit,always -F arch=b64 -S adjtimex
> chronyd -q
> 
> produces audit records like this:
> 
> type=SYSCALL msg=audit(1530616044.507:5): arch=c03e syscall=159
> success=yes exit=5 a0=7fff57e78c00 a1=0 a2=4 a3=7f754ae28c0a items=0
> ppid=626 pid=629 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=1 comm="chronyd" exe="/usr/sbin/chronyd"
> subj=system_u:system_r:kernel_t:s0 key=(null) type=PROCTITLE
> msg=audit(1530616044.507:5): proctitle=6368726F6E7964002D71 type=SYSCALL
> msg=audit(1530616044.507:6): arch=c03e syscall=159 success=yes exit=5
> a0=7fff57e78c00 a1=1 a2=1 a3=7f754ae28c0a items=0 ppid=626 pid=629 auid=0
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1
> comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:kernel_t:s0
> key=(null) type=PROCTITLE msg=audit(1530616044.507:6):
> proctitle=6368726F6E7964002D71 type=TIME_ADJNTPVAL
> msg=audit(1530616044.507:7): op=status old=64 new=8256 type=SYSCALL
> msg=audit(1530616044.507:7): arch=c03e syscall=159 success=yes exit=5
> a0=7fff57e78c00 a1=1 a2=1 a3=7f754ae28c0a items=0 ppid=626 pid=629 auid=0
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1
> comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:kernel_t:s0
> key=(null) type=PROCTITLE msg=audit(1530616044.507:7):
> proctitle=6368726F6E7964002D71 type=TIME_ADJNTPVAL
> msg=audit(1530616044.507:8): op=status old=8256 new=8257 type=SYSCALL
> msg=audit(1530616044.507:8): arch=c03e syscall=159 success=yes exit=5
> a0=7fff57e78ab0 a1=0 a2=55e129c850c0 a3=7f754ae28c0a items=0 ppid=626
> pid=629 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=1 comm="chronyd" exe="/usr/sbin/chronyd"
> subj=system_u:system_r:kernel_t:s0 key=(null) type=PROCTITLE
> msg=audit(1530616044.507:8): proctitle=6368726F6E7964002D71
> type=TIME_ADJNTPVAL msg=audit(1530616044.507:9): op=status old=8257 new=64
> type=SYSCALL msg=audit(1530616044.507:9): arch=c03e syscall=159
> success=yes exit=5 a0=7fff57e78ab0 a1=0 a2=55e129c850c0 a3=7f754ae28c0a
> items=0 ppid=626 pid=629 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=(none) ses=1 comm="chronyd" exe="/usr/sbin/chronyd"
> subj=system_u:system_r:kernel_t:s0 key=(null) type=PROCTITLE
> msg=audit(1530616044.507:9): proctitle=6368726F6E7964002D71 type=SYSCALL
> msg=audit(1530616044.507:10): arch=c03e syscall=159 success=yes exit=5
> a0=7fff57e78a70 a1=0 a2=55e129c850c0 a3=7f754ae28c0a items=0 ppid=626
> pid=629 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=1 comm="chronyd" exe="/usr/sbin/chronyd"
> subj=system_u:system_r:kernel_t:s0 key=(null) type=PROCTITLE
> msg=audit(1530616044.507:10): proctitle=6368726F6E7964002D71
> type=TIME_ADJNTPVAL msg=audit(1530616044.511:11): op=freq old=0
> new=49180377088000 type=SYSCALL msg=audit(1530616044.511:11):
> arch=c03e syscall=159 success=yes exit=5 a0=7fff57e78ad0 a1=0 a2=2710
> a3=f42f82a80 items=0 ppid=626 pid=629 auid=0 uid=385 gid=382 euid=385
> suid=385 fsuid=385 egid=382 sgid=382 fsgid=382 tty=(none) ses=1
> comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:kernel_t:s0
> key=(null) type=PROCTITLE msg=audit(1530616044.511:11):
> proctitle=6368726F6E7964002D71 type=SYSCALL msg=audit(1530616044.521:12):
> arch=c03e syscall=159 success=yes exit=5 a0=7fff57e78b40 a1=1 a2=40
> a3=f91f6ef84fbab items=0 ppid=626 pid=629 auid=0 uid=385 gid=382 euid=385
> suid=385 fsuid=385 egid=382 sgid=382 fsgid=382 tty=(none) ses=1
> comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:kernel_t:s0
> key=(null) type=PROCTITLE msg=audit(1530616044.521:12):
> proctitle=6368726F6E7964002D71 type=TIME_ADJNTPVAL
> msg=audit(1530616049.652:13): op=status old=64 new=8256 type=SYSCALL
> msg=audit(1530616049.652:13): arch=c03e syscall=159 success=yes exit=5
> a0=7fff57e78270 a1=1 a2=fff0 a3=137b828205ca12 items=0
> ppid=626 pid=629 auid=0 uid=385 gid=382 euid=385 suid=385 fsuid=385
> egid=382 sgid=382 fsgid=382 tty=(none) ses=1 comm="chronyd"
> exe="/usr/sbin/chronyd" 

Re: [RFC PATCH ghak10 v6 1/2] timekeeping: Audit clock adjustments

[Steve Grubb]

On Thursday, March 7, 2019 7:32:53 AM EST Ondrej Mosnacek wrote:
> Emit an audit record whenever the system clock is changed (i.e. shifted
> by a non-zero offset) by a syscall from userspace. The syscalls than can
> (at the time of writing) trigger such record are:
>   - settimeofday(2), stime(2), clock_settime(2) -- via
> do_settimeofday64()
>   - adjtimex(2), clock_adjtime(2) -- via do_adjtimex()
> 
> The new records have type AUDIT_TIME_INJOFFSET and contain the following
> fields:
>   - sec -- the 'seconds' part of the offset
>   - nsec -- the 'nanoseconds' part of the offset
> 
> For reference, running the following commands:
> 
> auditctl -D
> auditctl -a exit,always -F arch=b64 -S adjtimex
> chronyd -q
> 
> triggers (among others) a syscall that produces audit records like this:
> 
> type=TIME_INJOFFSET msg=audit(1530616049.652:13): sec=-16 nsec=124887145
> type=SYSCALL msg=audit(1530616049.652:13): arch=c03e syscall=159
> success=yes exit=5 a0=7fff57e78270 a1=1 a2=fff0
> a3=137b828205ca12 items=0 ppid=626 pid=629 auid=0 uid=385 gid=382 euid=385
> suid=385 fsuid=385 egid=382 sgid=382 fsgid=382 tty=(none) ses=1
> comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:kernel_t:s0
> key=(null) type=PROCTITLE msg=audit(1530616049.652:13):
> proctitle=6368726F6E7964002D71 cd
> /home/omosnace/Dokumenty/Kernel/worktrees/audit/src/kernel/time s

This is needed for common criteria. Requirements are getting stricter in 
certifications of IT products that are time stamp sensitive. The record format 
looks fine to me.

Ack for the record format.

-Steve

> The above records have been produced by the following syscall from
> chronyd (as per strace output):
> 
> adjtimex({modes=ADJ_SETOFFSET|ADJ_NANO, offset=0, freq=750433,
> maxerror=1600, esterror=1600, status=STA_UNSYNC|STA_NANO,
> constant=2, precision=1, tolerance=32768000, time={tv_sec=1530616033,
> tv_usec=778717675}, tick=1, ppsfreq=0, jitter=0, shift=0, stabil=0,
> jitcnt=0, calcnt=0, errcnt=0, stbcnt=0, tai=0}) = 5 (TIME_ERROR)
> 
> (The struct timex fields above are from *after* the syscall was
> executed, so they contain the current (new) values as set from the
> kernel, except of the 'modes' field, which contains the original value
> sent by the caller.)
> 
> Signed-off-by: Ondrej Mosnacek 
> ---
>  include/linux/audit.h  | 15 +++
>  include/uapi/linux/audit.h |  1 +
>  kernel/auditsc.c   |  8 
>  kernel/time/timekeeping.c  |  6 ++
>  4 files changed, 30 insertions(+)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 1e69d9fe16da..43a60fbe74be 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -27,6 +27,7 @@
>  #include 
>  #include   /* LOOKUP_* */
>  #include 
> +#include 
> 
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -365,6 +366,7 @@ extern void __audit_log_capset(const struct cred *new,
> const struct cred *old); extern void __audit_mmap_fd(int fd, int flags);
>  extern void __audit_log_kern_module(char *name);
>  extern void __audit_fanotify(unsigned int response);
> +extern void __audit_tk_injoffset(struct timespec64 offset);
> 
>  static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
>  {
> @@ -467,6 +469,16 @@ static inline void audit_fanotify(unsigned int
> response) __audit_fanotify(response);
>  }
> 
> +static inline void audit_tk_injoffset(struct timespec64 offset)
> +{
> + /* ignore no-op events */
> + if (offset.tv_sec == 0 && offset.tv_nsec == 0)
> + return;
> +
> + if (!audit_dummy_context())
> + __audit_tk_injoffset(offset);
> +}
> +
>  extern int audit_n_rules;
>  extern int audit_signals;
>  #else /* CONFIG_AUDITSYSCALL */
> @@ -580,6 +592,9 @@ static inline void audit_log_kern_module(char *name)
>  static inline void audit_fanotify(unsigned int response)
>  { }
> 
> +static inline void audit_tk_injoffset(struct timespec64 offset)
> +{ }
> +
>  static inline void audit_ptrace(struct task_struct *t)
>  { }
>  #define audit_n_rules 0
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 36a7e3f18e69..2167d55bc800 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -114,6 +114,7 @@
>  #define AUDIT_REPLACE1329/* Replace auditd if this 
> packet 
unanswerd */
>  #define AUDIT_KERN_MODULE1330/* Kernel Module events */
>  #define AUDIT_FANOTIFY   1331/* Fanotify access decision */
> +#define AUDIT_TIME_INJOFFSET 1332/* Timekeeping offset injected */
> 
>  #define AUDIT_AVC1400/* SE Linux avc denial or grant */
>  #define AUDIT_SELINUX_ERR1401/* Internal SE Linux Errors */
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index d1eab1d4a930..781336d0f2de 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2512,6 +2512,14 @@ void __audit_fanotify(unsigned int response)
>  

Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled

[Steve Grubb]

On Mon, 28 Jan 2019 15:08:56 -0500
Paul Moore  wrote:

> On Mon, Jan 28, 2019 at 3:03 PM Steve Grubb  wrote:
> > On Mon, 28 Jan 2019 11:26:51 -0500
> > Paul Moore  wrote:
> >  
> > > On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia -
> > > DE/Ulm)  wrote:  
> > > > Hello Paul,
> > > >
> > > > On 28/01/2019 15:52, Paul Moore wrote:  
> > > > >>>>> time also enables syscall auditing; this patch simplifies
> > > > >>>>> the Kconfig menus by removing the option to disable
> > > > >>>>> syscall auditing when audit is selected and the target
> > > > >>>>> arch supports it.
> > > > >>>>>
> > > > >>>>> Signed-off-by: Paul Moore   
> > > > >>>> this patch is responsible for massive performance
> > > > >>>> degradation for those who used only
> > > > >>>> CONFIG_SECURITY_APPARMOR.
> > > > >>>>
> > > > >>>> And the numbers are, take the following test for instance:
> > > > >>>>
> > > > >>>> dd if=/dev/zero of=/dev/null count=2M
> > > > >>>>
> > > > >>>> ARM64:  500MB/s -> 350MB/s
> > > > >>>> ARM:400MB/s -> 300MB/s  
> > > > >>> Hi there.
> > > > >>>
> > > > >>> Out of curiosity, what kernel/distribution are you running,
> > > > >>> or is this a custom kernel compile?  Can you also share the
> > > > >>> output of 'auditctl  
> > > > >> This test was carried out with Linux 4.9. Custom built.  
> > > > > I suspected that was the case, thanks.
> > > > >  
> > > > >>> -l' from your system?  The general approach taken by
> > > > >>> everyone to turn-off the per-syscall audit overhead is to
> > > > >>> add the "-a never,task" rule to their audit configuration:
> > > > >>>
> > > > >>>  # auditctl -a never,task
> > > > >>>
> > > > >>> If you are using Fedora/CentOS/RHEL, or a similarly
> > > > >>> configured system,  
> > > > >> This is an embedded distribution. We are not using auditctl
> > > > >> or any other audit-related user-space packages.
> > > > >>  
> > > > >>> you can find this configuration in
> > > > >>> the /etc/audit/audit.rules file (be warned, that file is
> > > > >>> automatically generated based on /etc/audit/rules.d).  
> > > > >> I suppose in this case rule list must be empty. Is there a
> > > > >> way to check this without extra user-space packages?  
> > > > > Yes, unless you are loading rules through some other method I
> > > > > would expect that your audit rule list is empty.
> > > > >
> > > > > I'm not aware of any other tools besides auditctl to load
> > > > > audit rules into the kernel, although I haven't ever had a
> > > > > need for another tool so I haven't looked very hard.  If you
> > > > > didn't want to bring auditctl into your distribution, I
> > > > > expect it would be a rather trivial task to create a small
> > > > > tool to load a single "-a never,task" into the kernel.  
> > > >
> > > > I've done a quick test on my x86_64 PC and got the following
> > > > results:  
> > >
> > > ...
> > >  
> > > > Which brings me to an idea, that the subject patch should have
> > > > been accompanied by a default "never,task" rule inside the
> > > > kernel, otherwise you require an extra user-space package
> > > > (audit) just to bring Linux 4.5+ to 4.4 performance levels.  
> > >
> > > [NOTE: I dropped pmo...@redhat.com from the To/CC line, I left
> > > Red Hat for greener pastures several months ago.]
> > >
> > > Well, it generally hasn't been an issue as 1) most people that
> > > enable audit also enable syscall auditing and 2) most people that
> > > enable audit have some sort of audit userspace tools to work with
> > > the audit logs (and configure audit if necessary).  I don't want
> > > to diminish your report, but this change was made several years
> > > ago and we really

Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled

[Steve Grubb]

On Mon, 28 Jan 2019 11:26:51 -0500
Paul Moore  wrote:

> On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia - DE/Ulm)
>  wrote:
> > Hello Paul,
> >
> > On 28/01/2019 15:52, Paul Moore wrote:  
> > > time also enables syscall auditing; this patch simplifies the
> > > Kconfig menus by removing the option to disable syscall
> > > auditing when audit is selected and the target arch supports
> > > it.
> > >
> > > Signed-off-by: Paul Moore   
> >  this patch is responsible for massive performance degradation
> >  for those who used only CONFIG_SECURITY_APPARMOR.
> > 
> >  And the numbers are, take the following test for instance:
> > 
> >  dd if=/dev/zero of=/dev/null count=2M
> > 
> >  ARM64:  500MB/s -> 350MB/s
> >  ARM:400MB/s -> 300MB/s  
> > >>> Hi there.
> > >>>
> > >>> Out of curiosity, what kernel/distribution are you running, or
> > >>> is this a custom kernel compile?  Can you also share the output
> > >>> of 'auditctl  
> > >> This test was carried out with Linux 4.9. Custom built.  
> > > I suspected that was the case, thanks.
> > >  
> > >>> -l' from your system?  The general approach taken by everyone to
> > >>> turn-off the per-syscall audit overhead is to add the "-a
> > >>> never,task" rule to their audit configuration:
> > >>>
> > >>>  # auditctl -a never,task
> > >>>
> > >>> If you are using Fedora/CentOS/RHEL, or a similarly configured
> > >>> system,  
> > >> This is an embedded distribution. We are not using auditctl or
> > >> any other audit-related user-space packages.
> > >>  
> > >>> you can find this configuration in the /etc/audit/audit.rules
> > >>> file (be warned, that file is automatically generated based on
> > >>> /etc/audit/rules.d).  
> > >> I suppose in this case rule list must be empty. Is there a way
> > >> to check this without extra user-space packages?  
> > > Yes, unless you are loading rules through some other method I
> > > would expect that your audit rule list is empty.
> > >
> > > I'm not aware of any other tools besides auditctl to load audit
> > > rules into the kernel, although I haven't ever had a need for
> > > another tool so I haven't looked very hard.  If you didn't want
> > > to bring auditctl into your distribution, I expect it would be a
> > > rather trivial task to create a small tool to load a single "-a
> > > never,task" into the kernel.  
> >
> > I've done a quick test on my x86_64 PC and got the following
> > results:  
> 
> ...
> 
> > Which brings me to an idea, that the subject patch should have been
> > accompanied by a default "never,task" rule inside the kernel,
> > otherwise you require an extra user-space package (audit) just to
> > bring Linux 4.5+ to 4.4 performance levels.  
> 
> [NOTE: I dropped pmo...@redhat.com from the To/CC line, I left Red Hat
> for greener pastures several months ago.]
> 
> Well, it generally hasn't been an issue as 1) most people that enable
> audit also enable syscall auditing and 2) most people that enable
> audit have some sort of audit userspace tools to work with the audit
> logs (and configure audit if necessary).  I don't want to diminish
> your report, but this change was made several years ago and we really
> haven't heard of many issues surrounding the change.  If we can ever
> get all of the different arches to support syscall auditing, I'd love
> to get rid of the syscall auditing Kconfig knob entirely.
> 
> If you wanted to put together a patch that added a single "-a
> never,task" rule on boot I could get behind that, just make it default
> to off.

That will make processes unauditable for everyone. That's how it gets a
speedup is not entering into the audit machinery. I suppose its
possible that people may want MAC hardwired events but no syscall
events. I don't know if there are other kconfig audit options. but
maybe getting it down to audit enabled and syscall auditing as the only
choices is probably the most performant.

-Steve

Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records

[Steve Grubb]

On Thu, 17 Jan 2019 08:21:40 -0500
Paul Moore  wrote:

> On Thu, Jan 17, 2019 at 4:33 AM Steve Grubb  wrote:
> > On Mon, 14 Jan 2019 17:58:58 -0500
> > Paul Moore  wrote:
> >  
> > > On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs
> > >  wrote:  
> > > >
> > > > Tie syscall information to all CONFIG_CHANGE calls since they
> > > > are all a result of user actions.  
> >
> > Please don't tie syscall information to this. The syscall will be
> > sendto. We don't need that information, its implicit. Also, doing
> > this will possibly wreck things in libauparse. Please test the
> > events with ausearch --format csv and --format text. IFF the event
> > looks better or the same should we do this. If stuff disappears,
> > the patch is breaking things  
> 
> We've discussed this quite a bit already;

Yes, and you still don't seem be listening. You have to cooperate on
modifying events. We as a community need to respect each other's needs
and work together to solve problems. What this is saying sounds a lot
like I don't care if it breaks things, I'm gonna do it my way. Tough
luck.

You do not have to make sense of any of these events. So, what does it
really matter to you how the event is formed? What I'm asking for is
have these changes been vetted to ensure that they are not breaking
things?

> connecting associated records into a single event is something that
> should happen, needs to happen, and will happen.  Conceptually it
> makes no sense to record the syscall (and any other associated
> records) which triggers the audit configuration change, and the
> configuration change record itself as two distinct events - they are
> the same event.

Except that they are not. The design of the audit system is to save
disk space as much as possible by emitting single record events on
certain event types that are simple. To add a syscall to it adds useless
information (such as a socket address record), slows down processing,
and wastes disk space. If you get a SYSCALL record, that indicates that
you have triggered an event that the system admin has placed explicit
rules on. That is different than the common criteria required
configuration change event. 

>  We've also heard from a prominent user that
> associating records in this way is desirable.
> 
> If the ausearch csv and text audit log transformations can't handle
> this particular change, I would consider that a shortcoming of that
> code.  We have multi-record events now, and this is only going to
> increase in the future.

Isn't there some kind a guideline about not breaking user space?

-Steve

> Richard, if you can't make the requested changes to this patch and
> resubmit by ... let's say the middle of next week? that should be
> enough time, yes? ... please let me know and I'll make the changes and
> get this merged.
> 

Re: [PATCH ghak59 V3 2/4] audit: add syscall information to CONFIG_CHANGE records

[Steve Grubb]

On Mon, 14 Jan 2019 17:58:58 -0500
Paul Moore  wrote:

> On Mon, Dec 10, 2018 at 5:18 PM Richard Guy Briggs 
> wrote:
> >
> > Tie syscall information to all CONFIG_CHANGE calls since they are
> > all a result of user actions.

Please don't tie syscall information to this. The syscall will be
sendto. We don't need that information, its implicit. Also, doing this
will possibly wreck things in libauparse. Please test the events with
ausearch --format csv and --format text. IFF the event looks better or
the same should we do this. If stuff disappears, the patch is
breaking things

-Steve


> > Exclude user records from syscall context:
> > Since the function audit_log_common_recv_msg() is shared by a
> > number of AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_*
> > record types, and since the AUDIT_CONFIG_CHANGE message type has
> > been converted to a syscall accompanied record type, special-case
> > the AUDIT_USER_* range of messages so they remain standalone
> > records.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/59
> > See: https://github.com/linux-audit/audit-kernel/issues/50
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  kernel/audit.c  | 27 +++
> >  kernel/audit_fsnotify.c |  2 +-
> >  kernel/audit_tree.c |  2 +-
> >  kernel/audit_watch.c|  2 +-
> >  kernel/auditfilter.c|  2 +-
> >  5 files changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 0e8026423fbd..a321fea94cc6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1072,6 +1073,16 @@ static void audit_log_common_recv_msg(struct
> > audit_buffer **ab, u16 msg_type) audit_log_task_context(*ab);
> >  }
> >
> > +static inline void audit_log_user_recv_msg(struct audit_buffer
> > **ab, u16 msg_type) +{
> > +   audit_log_common_recv_msg(NULL, ab, msg_type);
> > +}  
> 
> This makes sense because this is used by "user" records ...
> 
> > +static inline void audit_log_config_change_alt(struct audit_buffer
> > **ab) +{
> > +   audit_log_common_recv_msg(audit_context(), ab,
> > AUDIT_CONFIG_CHANGE); +}  
> 
> ... and I don't believe this makes sense because there is no real
> logical grouping with the callers like there is for
> audit_log_user_recv_msg().
> 

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Tuesday, May 22, 2018 9:43:46 AM EDT Richard Guy Briggs wrote:
> On 2018-05-21 17:57, Stefan Berger wrote:
> > On 05/21/2018 02:30 PM, Steve Grubb wrote:
> > > Hello Stefan,
> > > 
> > > On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote:
> > > > On 05/21/2018 12:58 PM, Steve Grubb wrote:
> > > > > On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> > > > > > > audit_log_container_info() then releasing the local context. 
> > > > > > > This
> > > > > > > version of the record has additional concerns covered here:
> > > > > > > https://github.com/linux-audit/audit-kernel/issues/52
> > > > > > 
> > > > > > Following the discussion there and the concern with breaking user
> > > > > > space,
> > > > > > how can we split up the AUDIT_INTEGRITY_RULE that is used in
> > > > > > ima_audit_measurement() and ima_parse_rule(), without 'breaking
> > > > > > user
> > > > > > space'?
> > > > > > 
> > > > > > A message produced by ima_parse_rule() looks like this here:
> > > > > > 
> > > > > > type=INTEGRITY_RULE msg=audit(1526566213.870:305):
> > > > > > action="dont_measure"
> > > > > > fsmagic="0x9fa0" res=1
> > > > > 
> > > > > Why is action and fsmagic being logged as untrusted strings?
> > > > > Untrusted
> > > > > strings are used when an unprivileged user can affect the contents
> > > > > of the
> > > > > field such as creating a file with space or special characters in
> > > > > the
> > > > > name.
> > > > > 
> > > > > Also, subject and object information is missing. Who loaded this
> > > > > rule?
> > > > > 
> > > > > > in contrast to that an INTEGRITY_PCR record type:
> > > > > > 
> > > > > > type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0
> > > > > > auid=0
> > > > > > ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > > > > op="invalid_pcr" cause="open_writers" comm="scp"
> > > > > > name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1
> > > > > 
> > > > > Why is op & cause being logged as an untrusted string? This also
> > > > > has
> > > > > incomplete subject information.
> > > > 
> > > > It's calling audit_log_string() in both cases:
> > > > 
> > > > https://elixir.bootlin.com/linux/latest/source/security/integrity/int
> > > > egrity _audit.c#L48
> > > 
> > > I see. Looking things over, I see that it seems like it should do the
> > > right thing. But the original purpose for this function is here:
> > > 
> > > https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944
> > > 
> > > This is where it is logging an untrusted string and has to decide to
> > > encode it or just place it in quotes. If it has quotes, that means
> > > it's an untrusted string but has no control characters in it. I think
> > > you want to use audit_log_format() for any string that is trustworthy.
> > 
> > Replacing all occurrences (in IMA) of audit_log_string() with
> > audit_log_format().
> > 
> > > As an aside, I wonder why audit_log_string() is in the API when it is a
> > > helper to audit_log_untrustedstring() ?  Without understanding the
> > > rules of untrusted strings, it can't be used correctly without
> > > re-inventing audit_log_untrustedstring() by hand.
> > > 
> > > > > > Should some of the fields from INTEGRITY_PCR also appear in
> > > > > > INTEGRITY_RULE? If so, which ones?
> > > > > 
> > > > > pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> > > > > required to be searchable
> > > > > 
> > > > > > We could probably refactor the current  integrity_audit_message()
> > > > > > and
> > > > > > have ima_parse_rule() call into it to get those fields as well. I
> > > > > > suppose adding new fields to it wouldn't be considered breaking
> > > > > > user
> > > > > > space?
> > > > &

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Tuesday, May 22, 2018 9:43:46 AM EDT Richard Guy Briggs wrote:
> On 2018-05-21 17:57, Stefan Berger wrote:
> > On 05/21/2018 02:30 PM, Steve Grubb wrote:
> > > Hello Stefan,
> > > 
> > > On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote:
> > > > On 05/21/2018 12:58 PM, Steve Grubb wrote:
> > > > > On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> > > > > > > audit_log_container_info() then releasing the local context. 
> > > > > > > This
> > > > > > > version of the record has additional concerns covered here:
> > > > > > > https://github.com/linux-audit/audit-kernel/issues/52
> > > > > > 
> > > > > > Following the discussion there and the concern with breaking user
> > > > > > space,
> > > > > > how can we split up the AUDIT_INTEGRITY_RULE that is used in
> > > > > > ima_audit_measurement() and ima_parse_rule(), without 'breaking
> > > > > > user
> > > > > > space'?
> > > > > > 
> > > > > > A message produced by ima_parse_rule() looks like this here:
> > > > > > 
> > > > > > type=INTEGRITY_RULE msg=audit(1526566213.870:305):
> > > > > > action="dont_measure"
> > > > > > fsmagic="0x9fa0" res=1
> > > > > 
> > > > > Why is action and fsmagic being logged as untrusted strings?
> > > > > Untrusted
> > > > > strings are used when an unprivileged user can affect the contents
> > > > > of the
> > > > > field such as creating a file with space or special characters in
> > > > > the
> > > > > name.
> > > > > 
> > > > > Also, subject and object information is missing. Who loaded this
> > > > > rule?
> > > > > 
> > > > > > in contrast to that an INTEGRITY_PCR record type:
> > > > > > 
> > > > > > type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0
> > > > > > auid=0
> > > > > > ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > > > > op="invalid_pcr" cause="open_writers" comm="scp"
> > > > > > name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1
> > > > > 
> > > > > Why is op & cause being logged as an untrusted string? This also
> > > > > has
> > > > > incomplete subject information.
> > > > 
> > > > It's calling audit_log_string() in both cases:
> > > > 
> > > > https://elixir.bootlin.com/linux/latest/source/security/integrity/int
> > > > egrity _audit.c#L48
> > > 
> > > I see. Looking things over, I see that it seems like it should do the
> > > right thing. But the original purpose for this function is here:
> > > 
> > > https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944
> > > 
> > > This is where it is logging an untrusted string and has to decide to
> > > encode it or just place it in quotes. If it has quotes, that means
> > > it's an untrusted string but has no control characters in it. I think
> > > you want to use audit_log_format() for any string that is trustworthy.
> > 
> > Replacing all occurrences (in IMA) of audit_log_string() with
> > audit_log_format().
> > 
> > > As an aside, I wonder why audit_log_string() is in the API when it is a
> > > helper to audit_log_untrustedstring() ?  Without understanding the
> > > rules of untrusted strings, it can't be used correctly without
> > > re-inventing audit_log_untrustedstring() by hand.
> > > 
> > > > > > Should some of the fields from INTEGRITY_PCR also appear in
> > > > > > INTEGRITY_RULE? If so, which ones?
> > > > > 
> > > > > pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> > > > > required to be searchable
> > > > > 
> > > > > > We could probably refactor the current  integrity_audit_message()
> > > > > > and
> > > > > > have ima_parse_rule() call into it to get those fields as well. I
> > > > > > suppose adding new fields to it wouldn't be considered breaking
> > > > > > user
> > > > > > space?
> > > > &

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Monday, May 21, 2018 5:57:29 PM EDT Stefan Berger wrote:
>  Should some of the fields from INTEGRITY_PCR also appear in
>  INTEGRITY_RULE? If so, which ones?
> >>> 
> >>> pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> >>> required to be searchable
> >>> 
>  We could probably refactor the current  integrity_audit_message() and
>  have ima_parse_rule() call into it to get those fields as well. I
>  suppose adding new fields to it wouldn't be considered breaking user
>  space?
> >>> 
> >>> The audit user space utilities pretty much expects those fields in that
> >>> order for any IMA originating events. You can add things like op or
> >>> cause before
> >> 
> >> We will call into audit_log_task, which will put the parameters into
> >> correct order:
> >> 
> >> auid uid gid ses subj pid comm exe
> > 
> > I'm telling you what the correct order is.  :-)  A long time ago, the IMA
> 
>  Thanks. Was getting confused.
> 
> > system had audit events with the order I'm mentioning. For example,
> > here's one from a log I collected back in 2013:
> > 
> > type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=kernel op="add_template_measure"
> > cause="hash_added" comm="init" name="01parse-kernel.sh" dev=rootfs
> > ino=5413 res=0
> > 
> > it was missing "tty" and "exe", but the order is as I mentioned. The
> > expectation is that INTEGRITY events maintain this established order
> > across all events.
> 
> I am *appending* exe= and tty= now:
> 
> type=INTEGRITY_PCR msg=audit(1526939047.809:305): pid=1609 uid=0 auid=0
> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> op="invalid_pcr" cause="open_writers" comm="ssh"
> name="/var/lib/sss/mc/passwd" dev="dm-0" ino=1962679 res=1
> exe="/usr/bin/ssh" tty=tty2

It is safe to put them where they belong. The tools currently skip over tty 
and exe if they would be present. So, nothing would get messed up. Its very 
simple to add an "if" statement to check for these new fields and collect 
them for searching. Also, "res" is traditionally the last field in any event.

Thanks,
-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Monday, May 21, 2018 5:57:29 PM EDT Stefan Berger wrote:
>  Should some of the fields from INTEGRITY_PCR also appear in
>  INTEGRITY_RULE? If so, which ones?
> >>> 
> >>> pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> >>> required to be searchable
> >>> 
>  We could probably refactor the current  integrity_audit_message() and
>  have ima_parse_rule() call into it to get those fields as well. I
>  suppose adding new fields to it wouldn't be considered breaking user
>  space?
> >>> 
> >>> The audit user space utilities pretty much expects those fields in that
> >>> order for any IMA originating events. You can add things like op or
> >>> cause before
> >> 
> >> We will call into audit_log_task, which will put the parameters into
> >> correct order:
> >> 
> >> auid uid gid ses subj pid comm exe
> > 
> > I'm telling you what the correct order is.  :-)  A long time ago, the IMA
> 
>  Thanks. Was getting confused.
> 
> > system had audit events with the order I'm mentioning. For example,
> > here's one from a log I collected back in 2013:
> > 
> > type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=kernel op="add_template_measure"
> > cause="hash_added" comm="init" name="01parse-kernel.sh" dev=rootfs
> > ino=5413 res=0
> > 
> > it was missing "tty" and "exe", but the order is as I mentioned. The
> > expectation is that INTEGRITY events maintain this established order
> > across all events.
> 
> I am *appending* exe= and tty= now:
> 
> type=INTEGRITY_PCR msg=audit(1526939047.809:305): pid=1609 uid=0 auid=0
> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> op="invalid_pcr" cause="open_writers" comm="ssh"
> name="/var/lib/sss/mc/passwd" dev="dm-0" ino=1962679 res=1
> exe="/usr/bin/ssh" tty=tty2

It is safe to put them where they belong. The tools currently skip over tty 
and exe if they would be present. So, nothing would get messed up. Its very 
simple to add an "if" statement to check for these new fields and collect 
them for searching. Also, "res" is traditionally the last field in any event.

Thanks,
-Steve

Re: [RFC PATCH ghak32 V2 03/13] audit: log container info of syscalls

[Steve Grubb]

On Thursday, May 17, 2018 5:41:02 PM EDT Richard Guy Briggs wrote:
> On 2018-05-17 17:09, Steve Grubb wrote:
> > On Fri, 16 Mar 2018 05:00:30 -0400
> > 
> > Richard Guy Briggs <r...@redhat.com> wrote:
> > > Create a new audit record AUDIT_CONTAINER_INFO to document the
> > > container ID of a process if it is present.
> > 
> > As mentioned in a previous email, I think AUDIT_CONTAINER is more
> > suitable for the container record. One more comment below...
> > 
> > > Called from audit_log_exit(), syscalls are covered.
> > > 
> > > A sample raw event:
> > > type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> > > success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> > > ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > > sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > key="tmpcontainerid" type=CWD msg=audit(1519924845.499:257):
> > > cwd="/root" type=PATH msg=audit(1519924845.499:257): item=0
> > > name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0
> > > rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT
> > > cap_fp= cap_fi= cap_fe=0 cap_fver=0
> > > type=PATH msg=audit(1519924845.499:257): item=1
> > > name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0
> > > ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> > > nametype=CREATE cap_fp= cap_fi=
> > > cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1519924845.499:257):
> > > proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F7
> > > 46D702F746D70636F6E7461696E65726964 type=CONTAINER_INFO
> > > msg=audit(1519924845.499:257): op=task
> > > contid=123458
> > > 
> > > See: https://github.com/linux-audit/audit-kernel/issues/32
> > > Signed-off-by: Richard Guy Briggs <r...@redhat.com>
> > > ---
> > > 
> > >  include/linux/audit.h  |  5 +
> > >  include/uapi/linux/audit.h |  1 +
> > >  kernel/audit.c | 20 
> > >  kernel/auditsc.c   |  2 ++
> > >  4 files changed, 28 insertions(+)
> > > 
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index fe4ba3f..3acbe9d 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -154,6 +154,8 @@ extern void
> > > audit_log_link_denied(const char *operation, extern int
> > > audit_log_task_context(struct audit_buffer *ab); extern void
> > > audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk);
> > > +extern int audit_log_container_info(struct task_struct *tsk,
> > > +  struct audit_context *context);
> > > 
> > >  extern int   audit_update_lsm_rules(void);
> > > 
> > > @@ -205,6 +207,9 @@ static inline int audit_log_task_context(struct
> > > audit_buffer *ab) static inline void audit_log_task_info(struct
> > > audit_buffer *ab, struct task_struct *tsk)
> > > 
> > >  { }
> > > 
> > > +static inline int audit_log_container_info(struct task_struct *tsk,
> > > + struct audit_context
> > > *context); +{ }
> > > 
> > >  #define audit_enabled 0
> > >  #endif /* CONFIG_AUDIT */
> > > 
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 921a71f..e83ccbd 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -115,6 +115,7 @@
> > > 
> > >  #define AUDIT_REPLACE1329/* Replace auditd
> > > 
> > > if this packet unanswerd */ #define AUDIT_KERN_MODULE
> > > 1330  /* Kernel Module events */ #define
> > > AUDIT_FANOTIFY1331/* Fanotify access decision
> > > */ +#define AUDIT_CONTAINER_INFO  1332/* Container ID
> > > information */ #define AUDIT_AVC  1400/* SE
> > > Linux avc denial or grant */ #define AUDIT_SELINUX_ERR
> > > 1401  /* Internal SE Linux Errors */ diff --git
> > > a/kernel/audit.c b/kernel/audit.c index 3f2f143..a12f21f 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -2049,6 +2049,26 @@ void audit_log_session

Re: [RFC PATCH ghak32 V2 03/13] audit: log container info of syscalls

[Steve Grubb]

On Thursday, May 17, 2018 5:41:02 PM EDT Richard Guy Briggs wrote:
> On 2018-05-17 17:09, Steve Grubb wrote:
> > On Fri, 16 Mar 2018 05:00:30 -0400
> > 
> > Richard Guy Briggs  wrote:
> > > Create a new audit record AUDIT_CONTAINER_INFO to document the
> > > container ID of a process if it is present.
> > 
> > As mentioned in a previous email, I think AUDIT_CONTAINER is more
> > suitable for the container record. One more comment below...
> > 
> > > Called from audit_log_exit(), syscalls are covered.
> > > 
> > > A sample raw event:
> > > type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> > > success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> > > ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > > sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > key="tmpcontainerid" type=CWD msg=audit(1519924845.499:257):
> > > cwd="/root" type=PATH msg=audit(1519924845.499:257): item=0
> > > name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0
> > > rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT
> > > cap_fp= cap_fi= cap_fe=0 cap_fver=0
> > > type=PATH msg=audit(1519924845.499:257): item=1
> > > name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0
> > > ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> > > nametype=CREATE cap_fp= cap_fi=
> > > cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1519924845.499:257):
> > > proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F7
> > > 46D702F746D70636F6E7461696E65726964 type=CONTAINER_INFO
> > > msg=audit(1519924845.499:257): op=task
> > > contid=123458
> > > 
> > > See: https://github.com/linux-audit/audit-kernel/issues/32
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > 
> > >  include/linux/audit.h  |  5 +
> > >  include/uapi/linux/audit.h |  1 +
> > >  kernel/audit.c | 20 
> > >  kernel/auditsc.c   |  2 ++
> > >  4 files changed, 28 insertions(+)
> > > 
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index fe4ba3f..3acbe9d 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -154,6 +154,8 @@ extern void
> > > audit_log_link_denied(const char *operation, extern int
> > > audit_log_task_context(struct audit_buffer *ab); extern void
> > > audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk);
> > > +extern int audit_log_container_info(struct task_struct *tsk,
> > > +  struct audit_context *context);
> > > 
> > >  extern int   audit_update_lsm_rules(void);
> > > 
> > > @@ -205,6 +207,9 @@ static inline int audit_log_task_context(struct
> > > audit_buffer *ab) static inline void audit_log_task_info(struct
> > > audit_buffer *ab, struct task_struct *tsk)
> > > 
> > >  { }
> > > 
> > > +static inline int audit_log_container_info(struct task_struct *tsk,
> > > + struct audit_context
> > > *context); +{ }
> > > 
> > >  #define audit_enabled 0
> > >  #endif /* CONFIG_AUDIT */
> > > 
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 921a71f..e83ccbd 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -115,6 +115,7 @@
> > > 
> > >  #define AUDIT_REPLACE1329/* Replace auditd
> > > 
> > > if this packet unanswerd */ #define AUDIT_KERN_MODULE
> > > 1330  /* Kernel Module events */ #define
> > > AUDIT_FANOTIFY1331/* Fanotify access decision
> > > */ +#define AUDIT_CONTAINER_INFO  1332/* Container ID
> > > information */ #define AUDIT_AVC  1400/* SE
> > > Linux avc denial or grant */ #define AUDIT_SELINUX_ERR
> > > 1401  /* Internal SE Linux Errors */ diff --git
> > > a/kernel/audit.c b/kernel/audit.c index 3f2f143..a12f21f 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -2049,6 +2049,26 @@ void audit_log_session_info(struct
> > > audit_buffer *ab) audi

Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process

[Steve Grubb]

On Friday, March 16, 2018 5:00:40 AM EDT Richard Guy Briggs wrote:
> Add support for reading the container ID from the proc filesystem.

I think this could be useful in general. Please consider this to be part of 
the full patch set and not something merely used to debug the patches.

-Steve

> This is a read from the proc entry of the form /proc/PID/containerid
> where PID is the process ID of the task whose container ID is sought.
> 
> The read expects up to a u64 value (unset: 18446744073709551615).
> 
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/proc/base.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 6ce4fbe..f66d1e2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1300,6 +1300,21 @@ static ssize_t proc_sessionid_read(struct file *
> file, char __user * buf, .llseek  = generic_file_llseek,
>  };
> 
> +static ssize_t proc_containerid_read(struct file *file, char __user *buf,
> +   size_t count, loff_t *ppos)
> +{
> + struct inode *inode = file_inode(file);
> + struct task_struct *task = get_proc_task(inode);
> + ssize_t length;
> + char tmpbuf[TMPBUFLEN*2];
> +
> + if (!task)
> + return -ESRCH;
> + length = scnprintf(tmpbuf, TMPBUFLEN*2, "%llu",
> audit_get_containerid(task)); +   put_task_struct(task);
> + return simple_read_from_buffer(buf, count, ppos, tmpbuf, length);
> +}
> +
>  static ssize_t proc_containerid_write(struct file *file, const char __user
> *buf, size_t count, loff_t *ppos)
>  {
> @@ -1330,6 +1345,7 @@ static ssize_t proc_containerid_write(struct file
> *file, const char __user *buf, }
> 
>  static const struct file_operations proc_containerid_operations = {
> + .read   = proc_containerid_read,
>   .write  = proc_containerid_write,
>   .llseek = generic_file_llseek,
>  };
> @@ -2996,7 +3012,7 @@ static int proc_pid_patch_state(struct seq_file *m,
> struct pid_namespace *ns, #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",   S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
> @@ -3391,7 +3407,7 @@ static int proc_tid_comm_permission(struct inode
> *inode, int mask) #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",  S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),

Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process

[Steve Grubb]

On Friday, March 16, 2018 5:00:40 AM EDT Richard Guy Briggs wrote:
> Add support for reading the container ID from the proc filesystem.

I think this could be useful in general. Please consider this to be part of 
the full patch set and not something merely used to debug the patches.

-Steve

> This is a read from the proc entry of the form /proc/PID/containerid
> where PID is the process ID of the task whose container ID is sought.
> 
> The read expects up to a u64 value (unset: 18446744073709551615).
> 
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/proc/base.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 6ce4fbe..f66d1e2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1300,6 +1300,21 @@ static ssize_t proc_sessionid_read(struct file *
> file, char __user * buf, .llseek  = generic_file_llseek,
>  };
> 
> +static ssize_t proc_containerid_read(struct file *file, char __user *buf,
> +   size_t count, loff_t *ppos)
> +{
> + struct inode *inode = file_inode(file);
> + struct task_struct *task = get_proc_task(inode);
> + ssize_t length;
> + char tmpbuf[TMPBUFLEN*2];
> +
> + if (!task)
> + return -ESRCH;
> + length = scnprintf(tmpbuf, TMPBUFLEN*2, "%llu",
> audit_get_containerid(task)); +   put_task_struct(task);
> + return simple_read_from_buffer(buf, count, ppos, tmpbuf, length);
> +}
> +
>  static ssize_t proc_containerid_write(struct file *file, const char __user
> *buf, size_t count, loff_t *ppos)
>  {
> @@ -1330,6 +1345,7 @@ static ssize_t proc_containerid_write(struct file
> *file, const char __user *buf, }
> 
>  static const struct file_operations proc_containerid_operations = {
> + .read   = proc_containerid_read,
>   .write  = proc_containerid_write,
>   .llseek = generic_file_llseek,
>  };
> @@ -2996,7 +3012,7 @@ static int proc_pid_patch_state(struct seq_file *m,
> struct pid_namespace *ns, #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",   S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
> @@ -3391,7 +3407,7 @@ static int proc_tid_comm_permission(struct inode
> *inode, int mask) #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",  S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

Hello Stefan,

On Monday, May 21, 2018 2:04:08 PM EDT Stefan Berger wrote:
> On 05/21/2018 01:21 PM, Steve Grubb wrote:
> > On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote:
> >> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote:
> >>> On 2018-05-18 10:39, Mimi Zohar wrote:
> >>>> On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote:
> >>>>> On 05/18/2018 08:53 AM, Mimi Zohar wrote:
> >>>> [..]
> >>>> 
> >>>>>>>>> If so, which ones? We could probably refactor the current
> >>>>>>>>> integrity_audit_message() and have ima_parse_rule() call into it
> >>>>>>>>> to get those fields as well. I suppose adding new fields to it
> >>>>>>>>> wouldn't be considered breaking user space?
> >>>>>>>> 
> >>>>>>>> Changing the order of existing fields or inserting fields could
> >>>>>>>> break stuff and is strongly discouraged without a good reason, but
> >>>>>>>> appending fields is usually the right way to add information.
> >>>>>>>> 
> >>>>>>>> There are exceptions, and in this case, I'd pick the "more
> >>>>>>>> standard" of the formats for AUDIT_INTEGRITY_RULE
> >>>>>>>> (ima_audit_measurement?) and stick with that, abandoning the other
> >>>>>>>> format, renaming the less standard version of the record
> >>>>>>>> (ima_parse_rule?) and perhpas adopting that abandonned format for
> >>>>>>>> the new record type while using current->audit_context.
> >>>>>> 
> >>>>>> This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> >>>>>> ima_audit_measurement().  Could we rename type=1805 to be
> >>>>> 
> >>>>> So do we want to change both? I thought that what
> >>>>> ima_audit_measurement() produces looks ok but may not have a good
> >>>>> name for the 'type'. Now in this case I would not want to 'break user
> >>>>> space'. The only change I was going to make was to what
> >>>>> ima_parse_rule() produces.
> >>>> 
> >>>> The only change for now is separating the IMA policy rules from the
> >>>> IMA-audit messages.
> >>>> 
> >>>> Richard, when the containerid is appended to the IMA-audit messages,
> >>>> would we make the audit type name change then?
> >>> 
> >>> No, go ahead and make the change now.  I'm expecting that the
> >>> containerid record will just be another auxiliary record and should not
> >>> affect you folks.
> >> 
> >> To summarize, we need to disambiguate the 1805, as both
> >> ima_parse_rule() and ima_audit_measurement() are using the same number
> >> with different formats.  The main usage of 1805 that we are aware of
> >> is ima_audit_measurement().  Yet the "type=" name for
> >> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not
> >> INTEGRITY_RULE.
> >> 
> >> option 1: breaks both uses
> >> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> >> 
> >> option 2: breaks the most common usage
> >> 1805 - INTEGRITY_RULE - ima_parse_rule()
> >> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> >> 
> >> option 3: leaves the most common usage with the wrong name, and breaks
> >> the other less common usage
> >> 1805 - INTEGRITY_RULE - ima_audit_measurement()
> >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> >> 
> >> So option 3 is the best option?
> >> 
> >  From a user space perspective, I don't care as long the event is well
> >  formed
>
> Are you saying this because of the tools you referred to that require
> proper ordering and all fields need to be available?

Its because the order was established a long time ago. User space tools still 
expect that ordering.
 
> > (No unnecessary untrusted string logging) and we have the required fields
> > for searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And
> > the object is identifiable in the event.
> 
> There's at least one documented user that showed the existing format...
> 
> https://www.fireeye.com/blog/threat-research/2016/11/extending_linux_exec.h
> tml

Hmm. I see. If that event was ever sent to linux-audit mail list for 
feedback, we would have had some discussion because it's not a proper event. 
The order of the fields changed, new fields were added, untrusted string 
logging is being used, field names are not documented in the field name 
dictionary, existing field names are not being used, subject information is 
incomplete, results is missing, and its not entirely clear what the object 
is.

-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

Hello Stefan,

On Monday, May 21, 2018 2:04:08 PM EDT Stefan Berger wrote:
> On 05/21/2018 01:21 PM, Steve Grubb wrote:
> > On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote:
> >> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote:
> >>> On 2018-05-18 10:39, Mimi Zohar wrote:
> >>>> On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote:
> >>>>> On 05/18/2018 08:53 AM, Mimi Zohar wrote:
> >>>> [..]
> >>>> 
> >>>>>>>>> If so, which ones? We could probably refactor the current
> >>>>>>>>> integrity_audit_message() and have ima_parse_rule() call into it
> >>>>>>>>> to get those fields as well. I suppose adding new fields to it
> >>>>>>>>> wouldn't be considered breaking user space?
> >>>>>>>> 
> >>>>>>>> Changing the order of existing fields or inserting fields could
> >>>>>>>> break stuff and is strongly discouraged without a good reason, but
> >>>>>>>> appending fields is usually the right way to add information.
> >>>>>>>> 
> >>>>>>>> There are exceptions, and in this case, I'd pick the "more
> >>>>>>>> standard" of the formats for AUDIT_INTEGRITY_RULE
> >>>>>>>> (ima_audit_measurement?) and stick with that, abandoning the other
> >>>>>>>> format, renaming the less standard version of the record
> >>>>>>>> (ima_parse_rule?) and perhpas adopting that abandonned format for
> >>>>>>>> the new record type while using current->audit_context.
> >>>>>> 
> >>>>>> This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> >>>>>> ima_audit_measurement().  Could we rename type=1805 to be
> >>>>> 
> >>>>> So do we want to change both? I thought that what
> >>>>> ima_audit_measurement() produces looks ok but may not have a good
> >>>>> name for the 'type'. Now in this case I would not want to 'break user
> >>>>> space'. The only change I was going to make was to what
> >>>>> ima_parse_rule() produces.
> >>>> 
> >>>> The only change for now is separating the IMA policy rules from the
> >>>> IMA-audit messages.
> >>>> 
> >>>> Richard, when the containerid is appended to the IMA-audit messages,
> >>>> would we make the audit type name change then?
> >>> 
> >>> No, go ahead and make the change now.  I'm expecting that the
> >>> containerid record will just be another auxiliary record and should not
> >>> affect you folks.
> >> 
> >> To summarize, we need to disambiguate the 1805, as both
> >> ima_parse_rule() and ima_audit_measurement() are using the same number
> >> with different formats.  The main usage of 1805 that we are aware of
> >> is ima_audit_measurement().  Yet the "type=" name for
> >> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not
> >> INTEGRITY_RULE.
> >> 
> >> option 1: breaks both uses
> >> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> >> 
> >> option 2: breaks the most common usage
> >> 1805 - INTEGRITY_RULE - ima_parse_rule()
> >> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> >> 
> >> option 3: leaves the most common usage with the wrong name, and breaks
> >> the other less common usage
> >> 1805 - INTEGRITY_RULE - ima_audit_measurement()
> >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> >> 
> >> So option 3 is the best option?
> >> 
> >  From a user space perspective, I don't care as long the event is well
> >  formed
>
> Are you saying this because of the tools you referred to that require
> proper ordering and all fields need to be available?

Its because the order was established a long time ago. User space tools still 
expect that ordering.
 
> > (No unnecessary untrusted string logging) and we have the required fields
> > for searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And
> > the object is identifiable in the event.
> 
> There's at least one documented user that showed the existing format...
> 
> https://www.fireeye.com/blog/threat-research/2016/11/extending_linux_exec.h
> tml

Hmm. I see. If that event was ever sent to linux-audit mail list for 
feedback, we would have had some discussion because it's not a proper event. 
The order of the fields changed, new fields were added, untrusted string 
logging is being used, field names are not documented in the field name 
dictionary, existing field names are not being used, subject information is 
incomplete, results is missing, and its not entirely clear what the object 
is.

-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

Hello Stefan,

On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote:
> On 05/21/2018 12:58 PM, Steve Grubb wrote:
> > On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> >>> audit_log_container_info() then releasing the local context.  This
> >>> version of the record has additional concerns covered here:
> >>> https://github.com/linux-audit/audit-kernel/issues/52
> >> 
> >> Following the discussion there and the concern with breaking user space,
> >> how can we split up the AUDIT_INTEGRITY_RULE that is used in
> >> ima_audit_measurement() and ima_parse_rule(), without 'breaking user
> >> space'?
> >> 
> >> A message produced by ima_parse_rule() looks like this here:
> >> 
> >> type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure"
> >> fsmagic="0x9fa0" res=1
> > 
> > Why is action and fsmagic being logged as untrusted strings? Untrusted
> > strings are used when an unprivileged user can affect the contents of the
> > field such as creating a file with space or special characters in the
> > name.
> > 
> > Also, subject and object information is missing. Who loaded this rule?
> > 
> >> in contrast to that an INTEGRITY_PCR record type:
> >> 
> >> type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0
> >> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >> op="invalid_pcr" cause="open_writers" comm="scp"
> >> name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1
> > 
> > Why is op & cause being logged as an untrusted string? This also has
> > incomplete subject information.
> 
> It's calling audit_log_string() in both cases:
> 
> https://elixir.bootlin.com/linux/latest/source/security/integrity/integrity
> _audit.c#L48

I see. Looking things over, I see that it seems like it should do the right 
thing. But the original purpose for this function is here:

https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944

This is where it is logging an untrusted string and has to decide to encode 
it or just place it in quotes. If it has quotes, that means it's an untrusted 
string but has no control characters in it. I think you want to use 
audit_log_format() for any string that is trustworthy.


As an aside, I wonder why audit_log_string() is in the API when it is a 
helper to audit_log_untrustedstring() ?  Without understanding the rules of 
untrusted strings, it can't be used correctly without re-inventing 
audit_log_untrustedstring() by hand.


> >> Should some of the fields from INTEGRITY_PCR also appear in
> >> INTEGRITY_RULE? If so, which ones?
> > 
> > pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> > required to be searchable
> > 
> >> We could probably refactor the current  integrity_audit_message() and
> >> have ima_parse_rule() call into it to get those fields as well. I
> >> suppose adding new fields to it wouldn't be considered breaking user
> >> space?
> > 
> > The audit user space utilities pretty much expects those fields in that
> > order for any IMA originating events. You can add things like op or
> > cause before
>
> We will call into audit_log_task, which will put the parameters into
> correct order:
> 
> auid uid gid ses subj pid comm exe

I'm telling you what the correct order is.  :-)  A long time ago, the IMA 
system had audit events with the order I'm mentioning. For example, here's 
one from a log I collected back in 2013:

type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel op="add_template_measure" cause="hash_added" 
comm="init" name="01parse-kernel.sh" dev=rootfs ino=5413 res=0

it was missing "tty" and "exe", but the order is as I mentioned. The 
expectation is that INTEGRITY events maintain this established order across 
all events.

Thanks,
-Steve


> https://elixir.bootlin.com/linux/latest/source/kernel/auditsc.c#L2433
> 
> > that. The reason why you can do that is those additional fields are not
> > required to be searchable by common criteria.
> > 
> > -Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

Hello Stefan,

On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote:
> On 05/21/2018 12:58 PM, Steve Grubb wrote:
> > On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> >>> audit_log_container_info() then releasing the local context.  This
> >>> version of the record has additional concerns covered here:
> >>> https://github.com/linux-audit/audit-kernel/issues/52
> >> 
> >> Following the discussion there and the concern with breaking user space,
> >> how can we split up the AUDIT_INTEGRITY_RULE that is used in
> >> ima_audit_measurement() and ima_parse_rule(), without 'breaking user
> >> space'?
> >> 
> >> A message produced by ima_parse_rule() looks like this here:
> >> 
> >> type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure"
> >> fsmagic="0x9fa0" res=1
> > 
> > Why is action and fsmagic being logged as untrusted strings? Untrusted
> > strings are used when an unprivileged user can affect the contents of the
> > field such as creating a file with space or special characters in the
> > name.
> > 
> > Also, subject and object information is missing. Who loaded this rule?
> > 
> >> in contrast to that an INTEGRITY_PCR record type:
> >> 
> >> type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0
> >> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >> op="invalid_pcr" cause="open_writers" comm="scp"
> >> name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1
> > 
> > Why is op & cause being logged as an untrusted string? This also has
> > incomplete subject information.
> 
> It's calling audit_log_string() in both cases:
> 
> https://elixir.bootlin.com/linux/latest/source/security/integrity/integrity
> _audit.c#L48

I see. Looking things over, I see that it seems like it should do the right 
thing. But the original purpose for this function is here:

https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944

This is where it is logging an untrusted string and has to decide to encode 
it or just place it in quotes. If it has quotes, that means it's an untrusted 
string but has no control characters in it. I think you want to use 
audit_log_format() for any string that is trustworthy.


As an aside, I wonder why audit_log_string() is in the API when it is a 
helper to audit_log_untrustedstring() ?  Without understanding the rules of 
untrusted strings, it can't be used correctly without re-inventing 
audit_log_untrustedstring() by hand.


> >> Should some of the fields from INTEGRITY_PCR also appear in
> >> INTEGRITY_RULE? If so, which ones?
> > 
> > pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are
> > required to be searchable
> > 
> >> We could probably refactor the current  integrity_audit_message() and
> >> have ima_parse_rule() call into it to get those fields as well. I
> >> suppose adding new fields to it wouldn't be considered breaking user
> >> space?
> > 
> > The audit user space utilities pretty much expects those fields in that
> > order for any IMA originating events. You can add things like op or
> > cause before
>
> We will call into audit_log_task, which will put the parameters into
> correct order:
> 
> auid uid gid ses subj pid comm exe

I'm telling you what the correct order is.  :-)  A long time ago, the IMA 
system had audit events with the order I'm mentioning. For example, here's 
one from a log I collected back in 2013:

type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel op="add_template_measure" cause="hash_added" 
comm="init" name="01parse-kernel.sh" dev=rootfs ino=5413 res=0

it was missing "tty" and "exe", but the order is as I mentioned. The 
expectation is that INTEGRITY events maintain this established order across 
all events.

Thanks,
-Steve


> https://elixir.bootlin.com/linux/latest/source/kernel/auditsc.c#L2433
> 
> > that. The reason why you can do that is those additional fields are not
> > required to be searchable by common criteria.
> > 
> > -Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote:
> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote:
> > On 2018-05-18 10:39, Mimi Zohar wrote:
> > > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote:
> > > > On 05/18/2018 08:53 AM, Mimi Zohar wrote:
> > > [..]
> > > 
> > > >  If so, which ones? We could probably refactor the current
> > > >  integrity_audit_message() and have ima_parse_rule() call into it
> > > >  to get
> > > >  those fields as well. I suppose adding new fields to it wouldn't
> > > >  be
> > > >  considered breaking user space?
> > > > >>> 
> > > > >>> Changing the order of existing fields or inserting fields could
> > > > >>> break
> > > > >>> stuff and is strongly discouraged without a good reason, but
> > > > >>> appending
> > > > >>> fields is usually the right way to add information.
> > > > >>> 
> > > > >>> There are exceptions, and in this case, I'd pick the "more
> > > > >>> standard" of
> > > > >>> the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and
> > > > >>> stick
> > > > >>> with that, abandoning the other format, renaming the less
> > > > >>> standard
> > > > >>> version of the record (ima_parse_rule?) and perhpas adopting that
> > > > >>> abandonned format for the new record type while using
> > > > >>> current->audit_context.
> > > > > 
> > > > > This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> > > > > ima_audit_measurement().  Could we rename type=1805 to be
> > > > 
> > > > So do we want to change both? I thought that what
> > > > ima_audit_measurement() produces looks ok but may not have a good
> > > > name
> > > > for the 'type'. Now in this case I would not want to 'break user
> > > > space'.
> > > > The only change I was going to make was to what ima_parse_rule()
> > > > produces.
> > > 
> > > The only change for now is separating the IMA policy rules from the
> > > IMA-audit messages.
> > > 
> > > Richard, when the containerid is appended to the IMA-audit messages,
> > > would we make the audit type name change then?
> > 
> > No, go ahead and make the change now.  I'm expecting that the
> > containerid record will just be another auxiliary record and should not
> > affect you folks.
> 
> To summarize, we need to disambiguate the 1805, as both
> ima_parse_rule() and ima_audit_measurement() are using the same number
> with different formats.  The main usage of 1805 that we are aware of
> is ima_audit_measurement().  Yet the "type=" name for
> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not
> INTEGRITY_RULE.
> 
> option 1: breaks both uses
> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> 
> option 2: breaks the most common usage
> 1805 - INTEGRITY_RULE - ima_parse_rule()
> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> 
> option 3: leaves the most common usage with the wrong name, and breaks
> the other less common usage
> 1805 - INTEGRITY_RULE - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> 
> So option 3 is the best option?

>From a user space perspective, I don't care as long the event is well formed 
(No unnecessary untrusted string logging) and we have the required fields for 
searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And the 
object is identifiable in the event.

-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote:
> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote:
> > On 2018-05-18 10:39, Mimi Zohar wrote:
> > > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote:
> > > > On 05/18/2018 08:53 AM, Mimi Zohar wrote:
> > > [..]
> > > 
> > > >  If so, which ones? We could probably refactor the current
> > > >  integrity_audit_message() and have ima_parse_rule() call into it
> > > >  to get
> > > >  those fields as well. I suppose adding new fields to it wouldn't
> > > >  be
> > > >  considered breaking user space?
> > > > >>> 
> > > > >>> Changing the order of existing fields or inserting fields could
> > > > >>> break
> > > > >>> stuff and is strongly discouraged without a good reason, but
> > > > >>> appending
> > > > >>> fields is usually the right way to add information.
> > > > >>> 
> > > > >>> There are exceptions, and in this case, I'd pick the "more
> > > > >>> standard" of
> > > > >>> the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and
> > > > >>> stick
> > > > >>> with that, abandoning the other format, renaming the less
> > > > >>> standard
> > > > >>> version of the record (ima_parse_rule?) and perhpas adopting that
> > > > >>> abandonned format for the new record type while using
> > > > >>> current->audit_context.
> > > > > 
> > > > > This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> > > > > ima_audit_measurement().  Could we rename type=1805 to be
> > > > 
> > > > So do we want to change both? I thought that what
> > > > ima_audit_measurement() produces looks ok but may not have a good
> > > > name
> > > > for the 'type'. Now in this case I would not want to 'break user
> > > > space'.
> > > > The only change I was going to make was to what ima_parse_rule()
> > > > produces.
> > > 
> > > The only change for now is separating the IMA policy rules from the
> > > IMA-audit messages.
> > > 
> > > Richard, when the containerid is appended to the IMA-audit messages,
> > > would we make the audit type name change then?
> > 
> > No, go ahead and make the change now.  I'm expecting that the
> > containerid record will just be another auxiliary record and should not
> > affect you folks.
> 
> To summarize, we need to disambiguate the 1805, as both
> ima_parse_rule() and ima_audit_measurement() are using the same number
> with different formats.  The main usage of 1805 that we are aware of
> is ima_audit_measurement().  Yet the "type=" name for
> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not
> INTEGRITY_RULE.
> 
> option 1: breaks both uses
> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> 
> option 2: breaks the most common usage
> 1805 - INTEGRITY_RULE - ima_parse_rule()
> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> 
> option 3: leaves the most common usage with the wrong name, and breaks
> the other less common usage
> 1805 - INTEGRITY_RULE - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
> 
> So option 3 is the best option?

>From a user space perspective, I don't care as long the event is well formed 
(No unnecessary untrusted string logging) and we have the required fields for 
searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And the 
object is identifiable in the event.

-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> > audit_log_container_info() then releasing the local context.  This
> > version of the record has additional concerns covered here:
> > https://github.com/linux-audit/audit-kernel/issues/52
> 
> Following the discussion there and the concern with breaking user space,
> how can we split up the AUDIT_INTEGRITY_RULE that is used in
> ima_audit_measurement() and ima_parse_rule(), without 'breaking user
> space'?
> 
> A message produced by ima_parse_rule() looks like this here:
> 
> type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure"
> fsmagic="0x9fa0" res=1

Why is action and fsmagic being logged as untrusted strings? Untrusted 
strings are used when an unprivileged user can affect the contents of the 
field such as creating a file with space or special characters in the name.

Also, subject and object information is missing. Who loaded this rule?

> in contrast to that an INTEGRITY_PCR record type:
> 
> type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0
> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> op="invalid_pcr" cause="open_writers" comm="scp"
> name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1

Why is op & cause being logged as an untrusted string? This also has 
incomplete subject information.

> Should some of the fields from INTEGRITY_PCR also appear in
> INTEGRITY_RULE? If so, which ones? 

pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are required to 
be searchable

> We could probably refactor the current  integrity_audit_message() and have
> ima_parse_rule() call into it to get those fields as well. I suppose adding
> new fields to it wouldn't be considered breaking user space?

The audit user space utilities pretty much expects those fields in that order 
for any IMA originating events. You can add things like op or cause before 
that. The reason why you can do that is those additional fields are not 
required to be searchable by common criteria.

-Steve

Re: [PATCH] audit: add containerid support for IMA-audit

[Steve Grubb]

On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> > audit_log_container_info() then releasing the local context.  This
> > version of the record has additional concerns covered here:
> > https://github.com/linux-audit/audit-kernel/issues/52
> 
> Following the discussion there and the concern with breaking user space,
> how can we split up the AUDIT_INTEGRITY_RULE that is used in
> ima_audit_measurement() and ima_parse_rule(), without 'breaking user
> space'?
> 
> A message produced by ima_parse_rule() looks like this here:
> 
> type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure"
> fsmagic="0x9fa0" res=1

Why is action and fsmagic being logged as untrusted strings? Untrusted 
strings are used when an unprivileged user can affect the contents of the 
field such as creating a file with space or special characters in the name.

Also, subject and object information is missing. Who loaded this rule?

> in contrast to that an INTEGRITY_PCR record type:
> 
> type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0
> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> op="invalid_pcr" cause="open_writers" comm="scp"
> name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1

Why is op & cause being logged as an untrusted string? This also has 
incomplete subject information.

> Should some of the fields from INTEGRITY_PCR also appear in
> INTEGRITY_RULE? If so, which ones? 

pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are required to 
be searchable

> We could probably refactor the current  integrity_audit_message() and have
> ima_parse_rule() call into it to get those fields as well. I suppose adding
> new fields to it wouldn't be considered breaking user space?

The audit user space utilities pretty much expects those fields in that order 
for any IMA originating events. You can add things like op or cause before 
that. The reason why you can do that is those additional fields are not 
required to be searchable by common criteria.

-Steve

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Fri, 18 May 2018 11:21:06 -0400
Richard Guy Briggs <r...@redhat.com> wrote:

> On 2018-05-18 09:56, Steve Grubb wrote:
> > On Thu, 17 May 2018 17:56:00 -0400
> > Richard Guy Briggs <r...@redhat.com> wrote:
> >   
> > > > During syscall events, the path info is returned in a a record
> > > > simply called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So,
> > > > rather than calling the record that gets attached to everything
> > > > AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.
> > > 
> > > Considering the container initiation record is different than the
> > > record to document the container involved in an otherwise normal
> > > syscall, we need two names.  I don't have a strong opinion what
> > > they are.
> > > 
> > > I'd prefer AUDIT_CONTAIN and AUDIT_CONTAINER_INFO so that the two
> > > are different enough to be visually distinct while leaving
> > > AUDIT_CONTAINERID for the field type in patch 4 ("audit: add
> > > containerid filtering")  
> 
> (Sorry, I had intended AUDIT_CONTAINER for the first in that paragraph
> above.)
> 
> > How about AUDIT_CONTAINER for the auxiliary record? The one that
> > starts the container, I don't have a strong opinion on. Could be
> > AUDIT_CONTAINER_INIT, AUDIT_CONTAINER_START, AUDIT_CONTAINERID,
> > AUDIT_CONTAINER_ID, or something else. The API call that sets the ID
> > for filtering could be AUDIT_CID or AUDIT_CONTID if that helps
> > decide what the initial event might be. Normally, it should match
> > the field being filtered.  
> 
> Ok, I had shortened the record field name to "contid=" to be unique
> enough while not using too much netlink bandwidth.  I could have used
> "cid=" but that could be unobvious or ambiguous.  I didn't want to use
> the full "containerid=" due to that.  I suppose I could change the
> field name macro to AUDIT_CONTID.
> 
> For the one that starts the container, I'd prefer to leave the name a
> bit more general than "_INIT", "_START", so maybe I'll swap them
> around and use AUDIT_CONTAINER_INFO for the startup record, and use
> AUDIT_CONTAINER for the syscall auxiliary record.
> 
> Does that work?

I'll go along with that. Thanks. But making that swap frees up
AUDIT_CONTAINER_ID which could be the first event. But
AUDIT_CONTAINER_INFO is also fine with me.

Best Regards,
-Steve

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Fri, 18 May 2018 11:21:06 -0400
Richard Guy Briggs  wrote:

> On 2018-05-18 09:56, Steve Grubb wrote:
> > On Thu, 17 May 2018 17:56:00 -0400
> > Richard Guy Briggs  wrote:
> >   
> > > > During syscall events, the path info is returned in a a record
> > > > simply called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So,
> > > > rather than calling the record that gets attached to everything
> > > > AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.
> > > 
> > > Considering the container initiation record is different than the
> > > record to document the container involved in an otherwise normal
> > > syscall, we need two names.  I don't have a strong opinion what
> > > they are.
> > > 
> > > I'd prefer AUDIT_CONTAIN and AUDIT_CONTAINER_INFO so that the two
> > > are different enough to be visually distinct while leaving
> > > AUDIT_CONTAINERID for the field type in patch 4 ("audit: add
> > > containerid filtering")  
> 
> (Sorry, I had intended AUDIT_CONTAINER for the first in that paragraph
> above.)
> 
> > How about AUDIT_CONTAINER for the auxiliary record? The one that
> > starts the container, I don't have a strong opinion on. Could be
> > AUDIT_CONTAINER_INIT, AUDIT_CONTAINER_START, AUDIT_CONTAINERID,
> > AUDIT_CONTAINER_ID, or something else. The API call that sets the ID
> > for filtering could be AUDIT_CID or AUDIT_CONTID if that helps
> > decide what the initial event might be. Normally, it should match
> > the field being filtered.  
> 
> Ok, I had shortened the record field name to "contid=" to be unique
> enough while not using too much netlink bandwidth.  I could have used
> "cid=" but that could be unobvious or ambiguous.  I didn't want to use
> the full "containerid=" due to that.  I suppose I could change the
> field name macro to AUDIT_CONTID.
> 
> For the one that starts the container, I'd prefer to leave the name a
> bit more general than "_INIT", "_START", so maybe I'll swap them
> around and use AUDIT_CONTAINER_INFO for the startup record, and use
> AUDIT_CONTAINER for the syscall auxiliary record.
> 
> Does that work?

I'll go along with that. Thanks. But making that swap frees up
AUDIT_CONTAINER_ID which could be the first event. But
AUDIT_CONTAINER_INFO is also fine with me.

Best Regards,
-Steve

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Thu, 17 May 2018 17:56:00 -0400
Richard Guy Briggs  wrote:

> > During syscall events, the path info is returned in a a record
> > simply called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So,
> > rather than calling the record that gets attached to everything
> > AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.  
> 
> Considering the container initiation record is different than the
> record to document the container involved in an otherwise normal
> syscall, we need two names.  I don't have a strong opinion what they
> are.
> 
> I'd prefer AUDIT_CONTAIN and AUDIT_CONTAINER_INFO so that the two
> are different enough to be visually distinct while leaving
> AUDIT_CONTAINERID for the field type in patch 4 ("audit: add
> containerid filtering")

How about AUDIT_CONTAINER for the auxiliary record? The one that starts
the container, I don't have a strong opinion on. Could be
AUDIT_CONTAINER_INIT, AUDIT_CONTAINER_START, AUDIT_CONTAINERID,
AUDIT_CONTAINER_ID, or something else. The API call that sets the ID
for filtering could be AUDIT_CID or AUDIT_CONTID if that helps decide
what the initial event might be. Normally, it should match the field
being filtered.

Best Regards,
-Steve

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Thu, 17 May 2018 17:56:00 -0400
Richard Guy Briggs  wrote:

> > During syscall events, the path info is returned in a a record
> > simply called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So,
> > rather than calling the record that gets attached to everything
> > AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.  
> 
> Considering the container initiation record is different than the
> record to document the container involved in an otherwise normal
> syscall, we need two names.  I don't have a strong opinion what they
> are.
> 
> I'd prefer AUDIT_CONTAIN and AUDIT_CONTAINER_INFO so that the two
> are different enough to be visually distinct while leaving
> AUDIT_CONTAINERID for the field type in patch 4 ("audit: add
> containerid filtering")

How about AUDIT_CONTAINER for the auxiliary record? The one that starts
the container, I don't have a strong opinion on. Could be
AUDIT_CONTAINER_INIT, AUDIT_CONTAINER_START, AUDIT_CONTAINERID,
AUDIT_CONTAINER_ID, or something else. The API call that sets the ID
for filtering could be AUDIT_CID or AUDIT_CONTID if that helps decide
what the initial event might be. Normally, it should match the field
being filtered.

Best Regards,
-Steve

Re: [RFC PATCH ghak32 V2 03/13] audit: log container info of syscalls

[Steve Grubb]

On Fri, 16 Mar 2018 05:00:30 -0400
Richard Guy Briggs  wrote:

> Create a new audit record AUDIT_CONTAINER_INFO to document the
> container ID of a process if it is present.

As mentioned in a previous email, I think AUDIT_CONTAINER is more
suitable for the container record. One more comment below...

> Called from audit_log_exit(), syscalls are covered.
> 
> A sample raw event:
> type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> key="tmpcontainerid" type=CWD msg=audit(1519924845.499:257):
> cwd="/root" type=PATH msg=audit(1519924845.499:257): item=0
> name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0
> rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0
> type=PATH msg=audit(1519924845.499:257): item=1
> name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0
> ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> nametype=CREATE cap_fp= cap_fi=
> cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1519924845.499:257):
> proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> type=CONTAINER_INFO msg=audit(1519924845.499:257): op=task
> contid=123458
> 
> See: https://github.com/linux-audit/audit-kernel/issues/32
> Signed-off-by: Richard Guy Briggs 
> ---
>  include/linux/audit.h  |  5 +
>  include/uapi/linux/audit.h |  1 +
>  kernel/audit.c | 20 
>  kernel/auditsc.c   |  2 ++
>  4 files changed, 28 insertions(+)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index fe4ba3f..3acbe9d 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -154,6 +154,8 @@ extern void
> audit_log_link_denied(const char *operation, extern int
> audit_log_task_context(struct audit_buffer *ab); extern void
> audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk);
> +extern int audit_log_container_info(struct task_struct *tsk,
> +  struct audit_context *context);
>  
>  extern int   audit_update_lsm_rules(void);
>  
> @@ -205,6 +207,9 @@ static inline int audit_log_task_context(struct
> audit_buffer *ab) static inline void audit_log_task_info(struct
> audit_buffer *ab, struct task_struct *tsk)
>  { }
> +static inline int audit_log_container_info(struct task_struct *tsk,
> + struct audit_context
> *context); +{ }
>  #define audit_enabled 0
>  #endif /* CONFIG_AUDIT */
>  
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 921a71f..e83ccbd 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -115,6 +115,7 @@
>  #define AUDIT_REPLACE1329/* Replace auditd
> if this packet unanswerd */ #define AUDIT_KERN_MODULE
> 1330  /* Kernel Module events */ #define
> AUDIT_FANOTIFY1331/* Fanotify access decision
> */ +#define AUDIT_CONTAINER_INFO  1332/* Container ID
> information */ #define AUDIT_AVC  1400/* SE
> Linux avc denial or grant */ #define AUDIT_SELINUX_ERR
> 1401  /* Internal SE Linux Errors */ diff --git
> a/kernel/audit.c b/kernel/audit.c index 3f2f143..a12f21f 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -2049,6 +2049,26 @@ void audit_log_session_info(struct
> audit_buffer *ab) audit_log_format(ab, " auid=%u ses=%u", auid,
> sessionid); }
>  
> +/*
> + * audit_log_container_info - report container info
> + * @tsk: task to be recorded
> + * @context: task or local context for record
> + */
> +int audit_log_container_info(struct task_struct *tsk, struct
> audit_context *context) +{
> + struct audit_buffer *ab;
> +
> + if (!audit_containerid_set(tsk))
> + return 0;
> + /* Generate AUDIT_CONTAINER_INFO with container ID */
> + ab = audit_log_start(context, GFP_KERNEL,
> AUDIT_CONTAINER_INFO);
> + if (!ab)
> + return -ENOMEM;
> + audit_log_format(ab, "contid=%llu",
> audit_get_containerid(tsk));
> + audit_log_end(ab);
> + return 0;
> +}
> +
>  void audit_log_key(struct audit_buffer *ab, char *key)
>  {
>   audit_log_format(ab, " key=");
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index a6b0a52..65be110 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1453,6 +1453,8 @@ static void audit_log_exit(struct audit_context
> *context, struct task_struct *ts 
>   audit_log_proctitle(tsk, context);
>  
> + audit_log_container_info(tsk, context);

Would there be any problem moving audit_log_container_info before
audit_log_proctitle? There are some 

Re: [RFC PATCH ghak32 V2 03/13] audit: log container info of syscalls

[Steve Grubb]

On Fri, 16 Mar 2018 05:00:30 -0400
Richard Guy Briggs  wrote:

> Create a new audit record AUDIT_CONTAINER_INFO to document the
> container ID of a process if it is present.

As mentioned in a previous email, I think AUDIT_CONTAINER is more
suitable for the container record. One more comment below...

> Called from audit_log_exit(), syscalls are covered.
> 
> A sample raw event:
> type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> key="tmpcontainerid" type=CWD msg=audit(1519924845.499:257):
> cwd="/root" type=PATH msg=audit(1519924845.499:257): item=0
> name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0
> rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0
> type=PATH msg=audit(1519924845.499:257): item=1
> name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0
> ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> nametype=CREATE cap_fp= cap_fi=
> cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1519924845.499:257):
> proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> type=CONTAINER_INFO msg=audit(1519924845.499:257): op=task
> contid=123458
> 
> See: https://github.com/linux-audit/audit-kernel/issues/32
> Signed-off-by: Richard Guy Briggs 
> ---
>  include/linux/audit.h  |  5 +
>  include/uapi/linux/audit.h |  1 +
>  kernel/audit.c | 20 
>  kernel/auditsc.c   |  2 ++
>  4 files changed, 28 insertions(+)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index fe4ba3f..3acbe9d 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -154,6 +154,8 @@ extern void
> audit_log_link_denied(const char *operation, extern int
> audit_log_task_context(struct audit_buffer *ab); extern void
> audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk);
> +extern int audit_log_container_info(struct task_struct *tsk,
> +  struct audit_context *context);
>  
>  extern int   audit_update_lsm_rules(void);
>  
> @@ -205,6 +207,9 @@ static inline int audit_log_task_context(struct
> audit_buffer *ab) static inline void audit_log_task_info(struct
> audit_buffer *ab, struct task_struct *tsk)
>  { }
> +static inline int audit_log_container_info(struct task_struct *tsk,
> + struct audit_context
> *context); +{ }
>  #define audit_enabled 0
>  #endif /* CONFIG_AUDIT */
>  
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 921a71f..e83ccbd 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -115,6 +115,7 @@
>  #define AUDIT_REPLACE1329/* Replace auditd
> if this packet unanswerd */ #define AUDIT_KERN_MODULE
> 1330  /* Kernel Module events */ #define
> AUDIT_FANOTIFY1331/* Fanotify access decision
> */ +#define AUDIT_CONTAINER_INFO  1332/* Container ID
> information */ #define AUDIT_AVC  1400/* SE
> Linux avc denial or grant */ #define AUDIT_SELINUX_ERR
> 1401  /* Internal SE Linux Errors */ diff --git
> a/kernel/audit.c b/kernel/audit.c index 3f2f143..a12f21f 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -2049,6 +2049,26 @@ void audit_log_session_info(struct
> audit_buffer *ab) audit_log_format(ab, " auid=%u ses=%u", auid,
> sessionid); }
>  
> +/*
> + * audit_log_container_info - report container info
> + * @tsk: task to be recorded
> + * @context: task or local context for record
> + */
> +int audit_log_container_info(struct task_struct *tsk, struct
> audit_context *context) +{
> + struct audit_buffer *ab;
> +
> + if (!audit_containerid_set(tsk))
> + return 0;
> + /* Generate AUDIT_CONTAINER_INFO with container ID */
> + ab = audit_log_start(context, GFP_KERNEL,
> AUDIT_CONTAINER_INFO);
> + if (!ab)
> + return -ENOMEM;
> + audit_log_format(ab, "contid=%llu",
> audit_get_containerid(tsk));
> + audit_log_end(ab);
> + return 0;
> +}
> +
>  void audit_log_key(struct audit_buffer *ab, char *key)
>  {
>   audit_log_format(ab, " key=");
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index a6b0a52..65be110 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1453,6 +1453,8 @@ static void audit_log_exit(struct audit_context
> *context, struct task_struct *ts 
>   audit_log_proctitle(tsk, context);
>  
> + audit_log_container_info(tsk, context);

Would there be any problem moving audit_log_container_info before
audit_log_proctitle? There are some assumptions that proctitle is the
last 

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Fri, 16 Mar 2018 05:00:28 -0400
Richard Guy Briggs  wrote:

> Implement the proc fs write to set the audit container ID of a
> process, emitting an AUDIT_CONTAINER record to document the event.
> 
> This is a write from the container orchestrator task to a proc entry
> of the form /proc/PID/containerid where PID is the process ID of the
> newly created task that is to become the first task in a container,
> or an additional task added to a container.
> 
> The write expects up to a u64 value (unset: 18446744073709551615).
> 
> This will produce a record such as this:
> type=CONTAINER msg=audit(1519903238.968:261): op=set pid=596 uid=0
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0
> tty=pts0 ses=1 opid=596 old-contid=18446744073709551615 contid=123455
> res=0

The was one thing I was wondering about. Currently when we set the
loginuid, the record is AUDIT_LOGINUID. The corollary is that when we
set the container id, the event should be AUDIT_CONTAINERID or
AUDIT_CONTAINER_ID.

During syscall events, the path info is returned in a a record simply
called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So, rather than
calling the record that gets attached to everything
AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.


> The "op" field indicates an initial set.  The "pid" to "ses" fields
> are the orchestrator while the "opid" field is the object's PID, the
> process being "contained".  Old and new container ID values are given
> in the "contid" fields, while res indicates its success.
> 
> It is not permitted to self-set, unset or re-set the container ID.  A
> child inherits its parent's container ID, but then can be set only
> once after.
> 
> See: https://github.com/linux-audit/audit-kernel/issues/32
> 
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/proc/base.c | 37 
>  include/linux/audit.h  | 16 +
>  include/linux/init_task.h  |  4 ++-
>  include/linux/sched.h  |  1 +
>  include/uapi/linux/audit.h |  2 ++
>  kernel/auditsc.c   | 84
> ++ 6 files changed, 143
> insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 60316b5..6ce4fbe 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1299,6 +1299,41 @@ static ssize_t proc_sessionid_read(struct file
> * file, char __user * buf, .read  = proc_sessionid_read,
>   .llseek = generic_file_llseek,
>  };
> +
> +static ssize_t proc_containerid_write(struct file *file, const char
> __user *buf,
> +size_t count, loff_t *ppos)
> +{
> + struct inode *inode = file_inode(file);
> + u64 containerid;
> + int rv;
> + struct task_struct *task = get_proc_task(inode);
> +
> + if (!task)
> + return -ESRCH;
> + if (*ppos != 0) {
> + /* No partial writes. */
> + put_task_struct(task);
> + return -EINVAL;
> + }
> +
> + rv = kstrtou64_from_user(buf, count, 10, );
> + if (rv < 0) {
> + put_task_struct(task);
> + return rv;
> + }
> +
> + rv = audit_set_containerid(task, containerid);
> + put_task_struct(task);
> + if (rv < 0)
> + return rv;
> + return count;
> +}
> +
> +static const struct file_operations proc_containerid_operations = {
> + .write  = proc_containerid_write,
> + .llseek = generic_file_llseek,
> +};
> +
>  #endif
>  
>  #ifdef CONFIG_FAULT_INJECTION
> @@ -2961,6 +2996,7 @@ static int proc_pid_patch_state(struct seq_file
> *m, struct pid_namespace *ns, #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",   S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> + REG("containerid", S_IWUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR,
> proc_fault_inject_operations), @@ -3355,6 +3391,7 @@ static int
> proc_tid_comm_permission(struct inode *inode, int mask) #ifdef
> CONFIG_AUDITSYSCALL REG("loginuid",  S_IWUSR|S_IRUGO,
> proc_loginuid_operations), REG("sessionid",  S_IRUGO,
> proc_sessionid_operations),
> + REG("containerid", S_IWUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR,
> proc_fault_inject_operations), diff --git a/include/linux/audit.h
> b/include/linux/audit.h index af410d9..fe4ba3f 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -29,6 +29,7 @@
>  
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> +#define INVALID_CID AUDIT_CID_UNSET
>  
>  struct audit_sig_info {
>   uid_t   uid;
> @@ -321,6 +322,7 @@ static inline void audit_ptrace(struct
> task_struct *t) extern int auditsc_get_stamp(struct audit_context
> *ctx, struct timespec64 *t, unsigned int *serial);
>  extern 

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Steve Grubb]

On Fri, 16 Mar 2018 05:00:28 -0400
Richard Guy Briggs  wrote:

> Implement the proc fs write to set the audit container ID of a
> process, emitting an AUDIT_CONTAINER record to document the event.
> 
> This is a write from the container orchestrator task to a proc entry
> of the form /proc/PID/containerid where PID is the process ID of the
> newly created task that is to become the first task in a container,
> or an additional task added to a container.
> 
> The write expects up to a u64 value (unset: 18446744073709551615).
> 
> This will produce a record such as this:
> type=CONTAINER msg=audit(1519903238.968:261): op=set pid=596 uid=0
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0
> tty=pts0 ses=1 opid=596 old-contid=18446744073709551615 contid=123455
> res=0

The was one thing I was wondering about. Currently when we set the
loginuid, the record is AUDIT_LOGINUID. The corollary is that when we
set the container id, the event should be AUDIT_CONTAINERID or
AUDIT_CONTAINER_ID.

During syscall events, the path info is returned in a a record simply
called AUDIT_PATH, cwd info is returned in AUDIT_CWD. So, rather than
calling the record that gets attached to everything
AUDIT_CONTAINER_INFO, how about simply AUDIT_CONTAINER.


> The "op" field indicates an initial set.  The "pid" to "ses" fields
> are the orchestrator while the "opid" field is the object's PID, the
> process being "contained".  Old and new container ID values are given
> in the "contid" fields, while res indicates its success.
> 
> It is not permitted to self-set, unset or re-set the container ID.  A
> child inherits its parent's container ID, but then can be set only
> once after.
> 
> See: https://github.com/linux-audit/audit-kernel/issues/32
> 
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/proc/base.c | 37 
>  include/linux/audit.h  | 16 +
>  include/linux/init_task.h  |  4 ++-
>  include/linux/sched.h  |  1 +
>  include/uapi/linux/audit.h |  2 ++
>  kernel/auditsc.c   | 84
> ++ 6 files changed, 143
> insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 60316b5..6ce4fbe 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1299,6 +1299,41 @@ static ssize_t proc_sessionid_read(struct file
> * file, char __user * buf, .read  = proc_sessionid_read,
>   .llseek = generic_file_llseek,
>  };
> +
> +static ssize_t proc_containerid_write(struct file *file, const char
> __user *buf,
> +size_t count, loff_t *ppos)
> +{
> + struct inode *inode = file_inode(file);
> + u64 containerid;
> + int rv;
> + struct task_struct *task = get_proc_task(inode);
> +
> + if (!task)
> + return -ESRCH;
> + if (*ppos != 0) {
> + /* No partial writes. */
> + put_task_struct(task);
> + return -EINVAL;
> + }
> +
> + rv = kstrtou64_from_user(buf, count, 10, );
> + if (rv < 0) {
> + put_task_struct(task);
> + return rv;
> + }
> +
> + rv = audit_set_containerid(task, containerid);
> + put_task_struct(task);
> + if (rv < 0)
> + return rv;
> + return count;
> +}
> +
> +static const struct file_operations proc_containerid_operations = {
> + .write  = proc_containerid_write,
> + .llseek = generic_file_llseek,
> +};
> +
>  #endif
>  
>  #ifdef CONFIG_FAULT_INJECTION
> @@ -2961,6 +2996,7 @@ static int proc_pid_patch_state(struct seq_file
> *m, struct pid_namespace *ns, #ifdef CONFIG_AUDITSYSCALL
>   REG("loginuid",   S_IWUSR|S_IRUGO, proc_loginuid_operations),
>   REG("sessionid",  S_IRUGO, proc_sessionid_operations),
> + REG("containerid", S_IWUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR,
> proc_fault_inject_operations), @@ -3355,6 +3391,7 @@ static int
> proc_tid_comm_permission(struct inode *inode, int mask) #ifdef
> CONFIG_AUDITSYSCALL REG("loginuid",  S_IWUSR|S_IRUGO,
> proc_loginuid_operations), REG("sessionid",  S_IRUGO,
> proc_sessionid_operations),
> + REG("containerid", S_IWUSR, proc_containerid_operations),
>  #endif
>  #ifdef CONFIG_FAULT_INJECTION
>   REG("make-it-fail", S_IRUGO|S_IWUSR,
> proc_fault_inject_operations), diff --git a/include/linux/audit.h
> b/include/linux/audit.h index af410d9..fe4ba3f 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -29,6 +29,7 @@
>  
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> +#define INVALID_CID AUDIT_CID_UNSET
>  
>  struct audit_sig_info {
>   uid_t   uid;
> @@ -321,6 +322,7 @@ static inline void audit_ptrace(struct
> task_struct *t) extern int auditsc_get_stamp(struct audit_context
> *ctx, struct timespec64 *t, unsigned int *serial);
>  extern int audit_set_loginuid(kuid_t 

Re: [PATCH v3 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 9:08:14 PM EDT Tyler Hicks wrote:
> The decision to log a seccomp action will always be subject to the
> value of the kernel.seccomp.actions_logged sysctl, even for processes
> that are being inspected via the audit subsystem, in an upcoming patch.
> Therefore, we need to emit an audit record on attempts at writing to the
> actions_logged sysctl when auditing is enabled.
> 
> This patch updates the write handler for the actions_logged sysctl to
> emit an audit record on attempts to write to the sysctl. Successful
> writes to the sysctl will result in a record that includes a normalized
> list of logged actions in the "actions" field and a "res" field equal to
> 1. Unsuccessful writes to the sysctl will result in a record that
> doesn't include the "actions" field and has a "res" field equal to 0.
> 
> Not all unsuccessful writes to the sysctl are audited. For example, an
> audit record will not be emitted if an unprivileged process attempts to
> open the sysctl file for reading since that access control check is not
> part of the sysctl's write handler.
> 
> Below are some example audit records when writing various strings to the
> actions_logged sysctl.
> 
> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> sysctl previously was "kill_process kill_thread trap errno trace log",
> emits this audit record:
> 
>  type=CONFIG_CHANGE msg=audit(1525392371.454:120): op=seccomp-logging
>  actions=? old-actions=kill_process,kill_thread,trap,errno,trace,log
>  res=0
> 
> If you then write "kill_process kill_thread errno trace log", this audit
> record is emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525392401.645:126): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> 
> If you then write "log log errno trace kill_process kill_thread", which
> is unordered and contains the log action twice, it results in the same
> actions value as the previous record:
> 
>  type=CONFIG_CHANGE msg=audit(1525392436.354:132): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> 
> If you then write an empty string to the sysctl, this audit record is
> emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525392494.413:138): op=seccomp-logging
>  actions=(none) old-actions=kill_process,kill_thread,errno,trace,log
>  res=1
> 
> No audit records are generated when reading the actions_logged sysctl.

This appears to cover all the corner cases we talked about. ACK for the 
format of the records.

Thanks,
-Steve
 
> Suggested-by: Steve Grubb <sgr...@redhat.com>
> Signed-off-by: Tyler Hicks <tyhi...@canonical.com>
> ---
>  include/linux/audit.h |  5 +
>  kernel/auditsc.c  | 20 ++
>  kernel/seccomp.c  | 58
> +++ 3 files changed, 74
> insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 75d5b03..d4e35e7 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -233,6 +233,8 @@ extern void __audit_inode_child(struct inode *parent,
>   const struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> +extern void audit_seccomp_actions_logged(const char *names,
> +  const char *old_names, int res);
>  extern void __audit_ptrace(struct task_struct *t);
> 
>  static inline bool audit_dummy_context(void)
> @@ -502,6 +504,9 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) { }
>  static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) { }
> +static inline void audit_seccomp_actions_logged(const char *names,
> + const char *old_names, int res)
> +{ }
>  static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
>  {
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 4e0a4ac..5195a29 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2478,6 +2478,26 @@ void __audit_seccomp(unsigned long syscall, long
> signr, int code) audit_log_end(ab);
>  }
> 
> +void audit_seccomp_actions_logged(const char *names, const char
> *old_names, +   int res)
> +{
> + struct audit_buffer *ab;
> +
> + if (!audit_enabled)
> + return;
> +
> +

Re: [PATCH v3 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 9:08:14 PM EDT Tyler Hicks wrote:
> The decision to log a seccomp action will always be subject to the
> value of the kernel.seccomp.actions_logged sysctl, even for processes
> that are being inspected via the audit subsystem, in an upcoming patch.
> Therefore, we need to emit an audit record on attempts at writing to the
> actions_logged sysctl when auditing is enabled.
> 
> This patch updates the write handler for the actions_logged sysctl to
> emit an audit record on attempts to write to the sysctl. Successful
> writes to the sysctl will result in a record that includes a normalized
> list of logged actions in the "actions" field and a "res" field equal to
> 1. Unsuccessful writes to the sysctl will result in a record that
> doesn't include the "actions" field and has a "res" field equal to 0.
> 
> Not all unsuccessful writes to the sysctl are audited. For example, an
> audit record will not be emitted if an unprivileged process attempts to
> open the sysctl file for reading since that access control check is not
> part of the sysctl's write handler.
> 
> Below are some example audit records when writing various strings to the
> actions_logged sysctl.
> 
> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> sysctl previously was "kill_process kill_thread trap errno trace log",
> emits this audit record:
> 
>  type=CONFIG_CHANGE msg=audit(1525392371.454:120): op=seccomp-logging
>  actions=? old-actions=kill_process,kill_thread,trap,errno,trace,log
>  res=0
> 
> If you then write "kill_process kill_thread errno trace log", this audit
> record is emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525392401.645:126): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> 
> If you then write "log log errno trace kill_process kill_thread", which
> is unordered and contains the log action twice, it results in the same
> actions value as the previous record:
> 
>  type=CONFIG_CHANGE msg=audit(1525392436.354:132): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> 
> If you then write an empty string to the sysctl, this audit record is
> emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525392494.413:138): op=seccomp-logging
>  actions=(none) old-actions=kill_process,kill_thread,errno,trace,log
>  res=1
> 
> No audit records are generated when reading the actions_logged sysctl.

This appears to cover all the corner cases we talked about. ACK for the 
format of the records.

Thanks,
-Steve
 
> Suggested-by: Steve Grubb 
> Signed-off-by: Tyler Hicks 
> ---
>  include/linux/audit.h |  5 +
>  kernel/auditsc.c  | 20 ++
>  kernel/seccomp.c  | 58
> +++ 3 files changed, 74
> insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 75d5b03..d4e35e7 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -233,6 +233,8 @@ extern void __audit_inode_child(struct inode *parent,
>   const struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> +extern void audit_seccomp_actions_logged(const char *names,
> +  const char *old_names, int res);
>  extern void __audit_ptrace(struct task_struct *t);
> 
>  static inline bool audit_dummy_context(void)
> @@ -502,6 +504,9 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) { }
>  static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) { }
> +static inline void audit_seccomp_actions_logged(const char *names,
> + const char *old_names, int res)
> +{ }
>  static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
>  {
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 4e0a4ac..5195a29 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2478,6 +2478,26 @@ void __audit_seccomp(unsigned long syscall, long
> signr, int code) audit_log_end(ab);
>  }
> 
> +void audit_seccomp_actions_logged(const char *names, const char
> *old_names, +   int res)
> +{
> + struct audit_buffer *ab;
> +
> + if (!audit_enabled)
> + return;
> +
> + ab = audit_log_start(current->audit_contex

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 6:36:18 PM EDT Tyler Hicks wrote:
> On 05/03/2018 04:12 PM, Steve Grubb wrote:
> > On Thursday, May 3, 2018 4:51:36 PM EDT Tyler Hicks wrote:
> >> On 05/03/2018 03:48 PM, Paul Moore wrote:
> >>> On Thu, May 3, 2018 at 4:42 PM, Steve Grubb <sgr...@redhat.com> wrote:
> >>>> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> >>>>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb <sgr...@redhat.com> 
wrote:
> >>>>>> On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >>>>>>> The decision to log a seccomp action will always be subject to the
> >>>>>>> value of the kernel.seccomp.actions_logged sysctl, even for
> >>>>>>> processes
> >>>>>>> that are being inspected via the audit subsystem, in an upcoming
> >>>>>>> patch.
> >>>>>>> Therefore, we need to emit an audit record on attempts at writing
> >>>>>>> to
> >>>>>>> the
> >>>>>>> actions_logged sysctl when auditing is enabled.
> >>>>>>> 
> >>>>>>> This patch updates the write handler for the actions_logged sysctl
> >>>>>>> to
> >>>>>>> emit an audit record on attempts to write to the sysctl. Successful
> >>>>>>> writes to the sysctl will result in a record that includes a
> >>>>>>> normalized
> >>>>>>> list of logged actions in the "actions" field and a "res" field
> >>>>>>> equal
> >>>>>>> to
> >>>>>>> 0. Unsuccessful writes to the sysctl will result in a record that
> >>>>>>> doesn't include the "actions" field and has a "res" field equal to
> >>>>>>> 1.
> >>>>>>> 
> >>>>>>> Not all unsuccessful writes to the sysctl are audited. For example,
> >>>>>>> an
> >>>>>>> audit record will not be emitted if an unprivileged process
> >>>>>>> attempts
> >>>>>>> to
> >>>>>>> open the sysctl file for reading since that access control check is
> >>>>>>> not
> >>>>>>> part of the sysctl's write handler.
> >>>>>>> 
> >>>>>>> Below are some example audit records when writing various strings
> >>>>>>> to
> >>>>>>> the
> >>>>>>> actions_logged sysctl.
> >>>>>>> 
> >>>>>>> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >>>>>>> sysctl previously was "kill_process kill_thread trap errno trace
> >>>>>>> log",
> >>>>>>> 
> >>>>>>> emits this audit record:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275273.537:130):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >>>>>>> 
> >>>>>>> If you then write "kill_process kill_thread errno trace log", this
> >>>>>>> audit
> >>>>>>> 
> >>>>>>> record is emitted:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275310.208:136):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >>>>>>> 
> >>>>>>> If you then write the string "log log errno trace kill_process
> >>>>>>> kill_thread", which is unordered and contains the log action twice,
> >>>>>>> 
> >>>>>>> it results in the same actions value as the previous record:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275325.613:142):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>>>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >>>>>>> 
> >>>>>>> No audit records are generated when reading the actions_logged
> >>>&g

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 6:36:18 PM EDT Tyler Hicks wrote:
> On 05/03/2018 04:12 PM, Steve Grubb wrote:
> > On Thursday, May 3, 2018 4:51:36 PM EDT Tyler Hicks wrote:
> >> On 05/03/2018 03:48 PM, Paul Moore wrote:
> >>> On Thu, May 3, 2018 at 4:42 PM, Steve Grubb  wrote:
> >>>> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> >>>>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb  
wrote:
> >>>>>> On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >>>>>>> The decision to log a seccomp action will always be subject to the
> >>>>>>> value of the kernel.seccomp.actions_logged sysctl, even for
> >>>>>>> processes
> >>>>>>> that are being inspected via the audit subsystem, in an upcoming
> >>>>>>> patch.
> >>>>>>> Therefore, we need to emit an audit record on attempts at writing
> >>>>>>> to
> >>>>>>> the
> >>>>>>> actions_logged sysctl when auditing is enabled.
> >>>>>>> 
> >>>>>>> This patch updates the write handler for the actions_logged sysctl
> >>>>>>> to
> >>>>>>> emit an audit record on attempts to write to the sysctl. Successful
> >>>>>>> writes to the sysctl will result in a record that includes a
> >>>>>>> normalized
> >>>>>>> list of logged actions in the "actions" field and a "res" field
> >>>>>>> equal
> >>>>>>> to
> >>>>>>> 0. Unsuccessful writes to the sysctl will result in a record that
> >>>>>>> doesn't include the "actions" field and has a "res" field equal to
> >>>>>>> 1.
> >>>>>>> 
> >>>>>>> Not all unsuccessful writes to the sysctl are audited. For example,
> >>>>>>> an
> >>>>>>> audit record will not be emitted if an unprivileged process
> >>>>>>> attempts
> >>>>>>> to
> >>>>>>> open the sysctl file for reading since that access control check is
> >>>>>>> not
> >>>>>>> part of the sysctl's write handler.
> >>>>>>> 
> >>>>>>> Below are some example audit records when writing various strings
> >>>>>>> to
> >>>>>>> the
> >>>>>>> actions_logged sysctl.
> >>>>>>> 
> >>>>>>> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >>>>>>> sysctl previously was "kill_process kill_thread trap errno trace
> >>>>>>> log",
> >>>>>>> 
> >>>>>>> emits this audit record:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275273.537:130):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >>>>>>> 
> >>>>>>> If you then write "kill_process kill_thread errno trace log", this
> >>>>>>> audit
> >>>>>>> 
> >>>>>>> record is emitted:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275310.208:136):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >>>>>>> 
> >>>>>>> If you then write the string "log log errno trace kill_process
> >>>>>>> kill_thread", which is unordered and contains the log action twice,
> >>>>>>> 
> >>>>>>> it results in the same actions value as the previous record:
> >>>>>>>  type=CONFIG_CHANGE msg=audit(1525275325.613:142):
> >>>>>>>  op=seccomp-logging
> >>>>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>>>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >>>>>>> 
> >>>>>>> No audit records are generated when reading the actions_logged
> >>>>>>> sysctl.
> >>>>>&g

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 4:51:36 PM EDT Tyler Hicks wrote:
> On 05/03/2018 03:48 PM, Paul Moore wrote:
> > On Thu, May 3, 2018 at 4:42 PM, Steve Grubb <sgr...@redhat.com> wrote:
> >> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> >>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb <sgr...@redhat.com> wrote:
> >>>> On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >>>>> The decision to log a seccomp action will always be subject to the
> >>>>> value of the kernel.seccomp.actions_logged sysctl, even for processes
> >>>>> that are being inspected via the audit subsystem, in an upcoming
> >>>>> patch.
> >>>>> Therefore, we need to emit an audit record on attempts at writing to
> >>>>> the
> >>>>> actions_logged sysctl when auditing is enabled.
> >>>>> 
> >>>>> This patch updates the write handler for the actions_logged sysctl to
> >>>>> emit an audit record on attempts to write to the sysctl. Successful
> >>>>> writes to the sysctl will result in a record that includes a
> >>>>> normalized
> >>>>> list of logged actions in the "actions" field and a "res" field equal
> >>>>> to
> >>>>> 0. Unsuccessful writes to the sysctl will result in a record that
> >>>>> doesn't include the "actions" field and has a "res" field equal to 1.
> >>>>> 
> >>>>> Not all unsuccessful writes to the sysctl are audited. For example,
> >>>>> an
> >>>>> audit record will not be emitted if an unprivileged process attempts
> >>>>> to
> >>>>> open the sysctl file for reading since that access control check is
> >>>>> not
> >>>>> part of the sysctl's write handler.
> >>>>> 
> >>>>> Below are some example audit records when writing various strings to
> >>>>> the
> >>>>> actions_logged sysctl.
> >>>>> 
> >>>>> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >>>>> sysctl previously was "kill_process kill_thread trap errno trace
> >>>>> log",
> >>>>> 
> >>>>> emits this audit record:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
> >>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >>>>> 
> >>>>> If you then write "kill_process kill_thread errno trace log", this
> >>>>> audit
> >>>>> 
> >>>>> record is emitted:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
> >>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >>>>> 
> >>>>> If you then write the string "log log errno trace kill_process
> >>>>> kill_thread", which is unordered and contains the log action twice,
> >>>>> 
> >>>>> it results in the same actions value as the previous record:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
> >>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >>>>> 
> >>>>> No audit records are generated when reading the actions_logged
> >>>>> sysctl.
> >>>> 
> >>>> ACK for the format of the records.
> >>> 
> >>> I just wanted to clarify the record format with you Steve ... the
> >>> "actions" and "old-actions" fields may not be included in the record
> >>> in cases where there is an error building the action value string, are
> >>> you okay with that or would you prefer the fields to always be
> >>> included but with a "?" for the value?
> >> 
> >> A ? would be more in line with how other things are handled.
> > 
> > That's what I thought.
> > 
> > Would you mind putting together a v3 Tyler? :)
> 
> To be clear, "?" is only to be used when the call to
> seccomp_names_from_actions_logged() fails, right?

Yes and that is a question mark with no quotes in the audit record.

> If the sysctl write fails for some other reason, such as when an invalid
> action name is specified, can you confirm that you still want *no*
> "actions" field, 

Its best that fields do not disappear. In the case of invalid input, you can 
just leave the new value as ? so that nothing malicious can be injected into 
the logs

> the "old-actions" field to be the value prior to attempting the update to
> the sysctl, and res to be 0?

Yes

-Steve

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 4:51:36 PM EDT Tyler Hicks wrote:
> On 05/03/2018 03:48 PM, Paul Moore wrote:
> > On Thu, May 3, 2018 at 4:42 PM, Steve Grubb  wrote:
> >> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> >>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb  wrote:
> >>>> On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >>>>> The decision to log a seccomp action will always be subject to the
> >>>>> value of the kernel.seccomp.actions_logged sysctl, even for processes
> >>>>> that are being inspected via the audit subsystem, in an upcoming
> >>>>> patch.
> >>>>> Therefore, we need to emit an audit record on attempts at writing to
> >>>>> the
> >>>>> actions_logged sysctl when auditing is enabled.
> >>>>> 
> >>>>> This patch updates the write handler for the actions_logged sysctl to
> >>>>> emit an audit record on attempts to write to the sysctl. Successful
> >>>>> writes to the sysctl will result in a record that includes a
> >>>>> normalized
> >>>>> list of logged actions in the "actions" field and a "res" field equal
> >>>>> to
> >>>>> 0. Unsuccessful writes to the sysctl will result in a record that
> >>>>> doesn't include the "actions" field and has a "res" field equal to 1.
> >>>>> 
> >>>>> Not all unsuccessful writes to the sysctl are audited. For example,
> >>>>> an
> >>>>> audit record will not be emitted if an unprivileged process attempts
> >>>>> to
> >>>>> open the sysctl file for reading since that access control check is
> >>>>> not
> >>>>> part of the sysctl's write handler.
> >>>>> 
> >>>>> Below are some example audit records when writing various strings to
> >>>>> the
> >>>>> actions_logged sysctl.
> >>>>> 
> >>>>> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >>>>> sysctl previously was "kill_process kill_thread trap errno trace
> >>>>> log",
> >>>>> 
> >>>>> emits this audit record:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
> >>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >>>>> 
> >>>>> If you then write "kill_process kill_thread errno trace log", this
> >>>>> audit
> >>>>> 
> >>>>> record is emitted:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
> >>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >>>>> 
> >>>>> If you then write the string "log log errno trace kill_process
> >>>>> kill_thread", which is unordered and contains the log action twice,
> >>>>> 
> >>>>> it results in the same actions value as the previous record:
> >>>>>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
> >>>>>  actions=kill_process,kill_thread,errno,trace,log
> >>>>>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >>>>> 
> >>>>> No audit records are generated when reading the actions_logged
> >>>>> sysctl.
> >>>> 
> >>>> ACK for the format of the records.
> >>> 
> >>> I just wanted to clarify the record format with you Steve ... the
> >>> "actions" and "old-actions" fields may not be included in the record
> >>> in cases where there is an error building the action value string, are
> >>> you okay with that or would you prefer the fields to always be
> >>> included but with a "?" for the value?
> >> 
> >> A ? would be more in line with how other things are handled.
> > 
> > That's what I thought.
> > 
> > Would you mind putting together a v3 Tyler? :)
> 
> To be clear, "?" is only to be used when the call to
> seccomp_names_from_actions_logged() fails, right?

Yes and that is a question mark with no quotes in the audit record.

> If the sysctl write fails for some other reason, such as when an invalid
> action name is specified, can you confirm that you still want *no*
> "actions" field, 

Its best that fields do not disappear. In the case of invalid input, you can 
just leave the new value as ? so that nothing malicious can be injected into 
the logs

> the "old-actions" field to be the value prior to attempting the update to
> the sysctl, and res to be 0?

Yes

-Steve

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb <sgr...@redhat.com> wrote:
> > On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >> The decision to log a seccomp action will always be subject to the
> >> value of the kernel.seccomp.actions_logged sysctl, even for processes
> >> that are being inspected via the audit subsystem, in an upcoming patch.
> >> Therefore, we need to emit an audit record on attempts at writing to the
> >> actions_logged sysctl when auditing is enabled.
> >> 
> >> This patch updates the write handler for the actions_logged sysctl to
> >> emit an audit record on attempts to write to the sysctl. Successful
> >> writes to the sysctl will result in a record that includes a normalized
> >> list of logged actions in the "actions" field and a "res" field equal to
> >> 0. Unsuccessful writes to the sysctl will result in a record that
> >> doesn't include the "actions" field and has a "res" field equal to 1.
> >> 
> >> Not all unsuccessful writes to the sysctl are audited. For example, an
> >> audit record will not be emitted if an unprivileged process attempts to
> >> open the sysctl file for reading since that access control check is not
> >> part of the sysctl's write handler.
> >> 
> >> Below are some example audit records when writing various strings to the
> >> actions_logged sysctl.
> >> 
> >> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >> sysctl previously was "kill_process kill_thread trap errno trace log",
> >> 
> >> emits this audit record:
> >>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
> >>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >> 
> >> If you then write "kill_process kill_thread errno trace log", this audit
> >> 
> >> record is emitted:
> >>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
> >>  actions=kill_process,kill_thread,errno,trace,log
> >>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >> 
> >> If you then write the string "log log errno trace kill_process
> >> kill_thread", which is unordered and contains the log action twice,
> >> 
> >> it results in the same actions value as the previous record:
> >>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
> >>  actions=kill_process,kill_thread,errno,trace,log
> >>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >> 
> >> No audit records are generated when reading the actions_logged sysctl.
> > 
> > ACK for the format of the records.
> 
> I just wanted to clarify the record format with you Steve ... the
> "actions" and "old-actions" fields may not be included in the record
> in cases where there is an error building the action value string, are
> you okay with that or would you prefer the fields to always be
> included but with a "?" for the value?

A ? would be more in line with how other things are handled.

-Steve

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote:
> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb  wrote:
> > On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> >> The decision to log a seccomp action will always be subject to the
> >> value of the kernel.seccomp.actions_logged sysctl, even for processes
> >> that are being inspected via the audit subsystem, in an upcoming patch.
> >> Therefore, we need to emit an audit record on attempts at writing to the
> >> actions_logged sysctl when auditing is enabled.
> >> 
> >> This patch updates the write handler for the actions_logged sysctl to
> >> emit an audit record on attempts to write to the sysctl. Successful
> >> writes to the sysctl will result in a record that includes a normalized
> >> list of logged actions in the "actions" field and a "res" field equal to
> >> 0. Unsuccessful writes to the sysctl will result in a record that
> >> doesn't include the "actions" field and has a "res" field equal to 1.
> >> 
> >> Not all unsuccessful writes to the sysctl are audited. For example, an
> >> audit record will not be emitted if an unprivileged process attempts to
> >> open the sysctl file for reading since that access control check is not
> >> part of the sysctl's write handler.
> >> 
> >> Below are some example audit records when writing various strings to the
> >> actions_logged sysctl.
> >> 
> >> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> >> sysctl previously was "kill_process kill_thread trap errno trace log",
> >> 
> >> emits this audit record:
> >>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
> >>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> >> 
> >> If you then write "kill_process kill_thread errno trace log", this audit
> >> 
> >> record is emitted:
> >>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
> >>  actions=kill_process,kill_thread,errno,trace,log
> >>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> >> 
> >> If you then write the string "log log errno trace kill_process
> >> kill_thread", which is unordered and contains the log action twice,
> >> 
> >> it results in the same actions value as the previous record:
> >>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
> >>  actions=kill_process,kill_thread,errno,trace,log
> >>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> >> 
> >> No audit records are generated when reading the actions_logged sysctl.
> > 
> > ACK for the format of the records.
> 
> I just wanted to clarify the record format with you Steve ... the
> "actions" and "old-actions" fields may not be included in the record
> in cases where there is an error building the action value string, are
> you okay with that or would you prefer the fields to always be
> included but with a "?" for the value?

A ? would be more in line with how other things are handled.

-Steve

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> The decision to log a seccomp action will always be subject to the
> value of the kernel.seccomp.actions_logged sysctl, even for processes
> that are being inspected via the audit subsystem, in an upcoming patch.
> Therefore, we need to emit an audit record on attempts at writing to the
> actions_logged sysctl when auditing is enabled.
> 
> This patch updates the write handler for the actions_logged sysctl to
> emit an audit record on attempts to write to the sysctl. Successful
> writes to the sysctl will result in a record that includes a normalized
> list of logged actions in the "actions" field and a "res" field equal to
> 0. Unsuccessful writes to the sysctl will result in a record that
> doesn't include the "actions" field and has a "res" field equal to 1.
> 
> Not all unsuccessful writes to the sysctl are audited. For example, an
> audit record will not be emitted if an unprivileged process attempts to
> open the sysctl file for reading since that access control check is not
> part of the sysctl's write handler.
> 
> Below are some example audit records when writing various strings to the
> actions_logged sysctl.
> 
> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> sysctl previously was "kill_process kill_thread trap errno trace log",
> emits this audit record:
> 
>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> 
> If you then write "kill_process kill_thread errno trace log", this audit
> record is emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> 
> If you then write the string "log log errno trace kill_process
> kill_thread", which is unordered and contains the log action twice,
> it results in the same actions value as the previous record:
> 
>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> 
> No audit records are generated when reading the actions_logged sysctl.

ACK for the format of the records.

-Steve

> Suggested-by: Steve Grubb <sgr...@redhat.com>
> Signed-off-by: Tyler Hicks <tyhi...@canonical.com>
> ---
>  include/linux/audit.h |  5 +
>  kernel/auditsc.c  | 25 +
>  kernel/seccomp.c  | 51
> ++- 3 files changed, 72
> insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 75d5b03..d4e35e7 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -233,6 +233,8 @@ extern void __audit_inode_child(struct inode *parent,
>   const struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> +extern void audit_seccomp_actions_logged(const char *names,
> +  const char *old_names, int res);
>  extern void __audit_ptrace(struct task_struct *t);
> 
>  static inline bool audit_dummy_context(void)
> @@ -502,6 +504,9 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) { }
>  static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) { }
> +static inline void audit_seccomp_actions_logged(const char *names,
> + const char *old_names, int res)
> +{ }
>  static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
>  {
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 4e0a4ac..5a0b770 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2478,6 +2478,31 @@ void __audit_seccomp(unsigned long syscall, long
> signr, int code) audit_log_end(ab);
>  }
> 
> +void audit_seccomp_actions_logged(const char *names, const char
> *old_names, +   int res)
> +{
> + struct audit_buffer *ab;
> +
> + if (!audit_enabled)
> + return;
> +
> + ab = audit_log_start(current->audit_context, GFP_KERNEL,
> +  AUDIT_CONFIG_CHANGE);
> + if (unlikely(!ab))
> + return;
> +
> + audit_log_format(ab, "op=seccomp-logging");
> +
> + if (names)
> + audit_log_format(ab, " actions

Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> The decision to log a seccomp action will always be subject to the
> value of the kernel.seccomp.actions_logged sysctl, even for processes
> that are being inspected via the audit subsystem, in an upcoming patch.
> Therefore, we need to emit an audit record on attempts at writing to the
> actions_logged sysctl when auditing is enabled.
> 
> This patch updates the write handler for the actions_logged sysctl to
> emit an audit record on attempts to write to the sysctl. Successful
> writes to the sysctl will result in a record that includes a normalized
> list of logged actions in the "actions" field and a "res" field equal to
> 0. Unsuccessful writes to the sysctl will result in a record that
> doesn't include the "actions" field and has a "res" field equal to 1.
> 
> Not all unsuccessful writes to the sysctl are audited. For example, an
> audit record will not be emitted if an unprivileged process attempts to
> open the sysctl file for reading since that access control check is not
> part of the sysctl's write handler.
> 
> Below are some example audit records when writing various strings to the
> actions_logged sysctl.
> 
> Writing "not-a-real-action", when the kernel.seccomp.actions_logged
> sysctl previously was "kill_process kill_thread trap errno trace log",
> emits this audit record:
> 
>  type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=0
> 
> If you then write "kill_process kill_thread errno trace log", this audit
> record is emitted:
> 
>  type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
> 
> If you then write the string "log log errno trace kill_process
> kill_thread", which is unordered and contains the log action twice,
> it results in the same actions value as the previous record:
> 
>  type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
>  actions=kill_process,kill_thread,errno,trace,log
>  old-actions=kill_process,kill_thread,errno,trace,log res=1
> 
> No audit records are generated when reading the actions_logged sysctl.

ACK for the format of the records.

-Steve

> Suggested-by: Steve Grubb 
> Signed-off-by: Tyler Hicks 
> ---
>  include/linux/audit.h |  5 +
>  kernel/auditsc.c  | 25 +
>  kernel/seccomp.c  | 51
> ++- 3 files changed, 72
> insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 75d5b03..d4e35e7 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -233,6 +233,8 @@ extern void __audit_inode_child(struct inode *parent,
>   const struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> +extern void audit_seccomp_actions_logged(const char *names,
> +  const char *old_names, int res);
>  extern void __audit_ptrace(struct task_struct *t);
> 
>  static inline bool audit_dummy_context(void)
> @@ -502,6 +504,9 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) { }
>  static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) { }
> +static inline void audit_seccomp_actions_logged(const char *names,
> + const char *old_names, int res)
> +{ }
>  static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
>  {
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 4e0a4ac..5a0b770 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2478,6 +2478,31 @@ void __audit_seccomp(unsigned long syscall, long
> signr, int code) audit_log_end(ab);
>  }
> 
> +void audit_seccomp_actions_logged(const char *names, const char
> *old_names, +   int res)
> +{
> + struct audit_buffer *ab;
> +
> + if (!audit_enabled)
> + return;
> +
> + ab = audit_log_start(current->audit_context, GFP_KERNEL,
> +  AUDIT_CONFIG_CHANGE);
> + if (unlikely(!ab))
> + return;
> +
> + audit_log_format(ab, "op=seccomp-logging");
> +
> + if (names)
> + audit_log_format(ab, " actions=%s", names);
> +
> + if (old_names)

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote:
> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks <tyhi...@canonical.com> wrote:
> > The decision to log a seccomp action will always be subject to the
> > value of the kernel.seccomp.actions_logged sysctl, even for processes
> > that are being inspected via the audit subsystem, in an upcoming patch.
> > Therefore, we need to emit an audit record on attempts at writing to the
> > actions_logged sysctl when auditing is enabled.
> > 
> > This patch updates the write handler for the actions_logged sysctl to
> > emit an audit record on attempts to write to the sysctl. Successful
> > writes to the sysctl will result in a record that includes a normalized
> > list of logged actions in the "actions" field and a "res" field equal to
> > 0. Unsuccessful writes to the sysctl will result in a record that
> > doesn't include the "actions" field and has a "res" field equal to 1.
> > 
> > Not all unsuccessful writes to the sysctl are audited. For example, an
> > audit record will not be emitted if an unprivileged process attempts to
> > open the sysctl file for reading since that access control check is not
> > part of the sysctl's write handler.
> > 
> > Below are some example audit records when writing various strings to the
> > actions_logged sysctl.
> > 
> > Writing "not-a-real-action" emits:
> >  type=CONFIG_CHANGE msg=audit(1524600971.363:119): pid=1651 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging res=1
> > 
> > Writing "kill_process kill_thread errno trace log" emits:
> >  type=CONFIG_CHANGE msg=audit(1524601023.982:131): pid=1658 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging actions="kill_process kill_thread errno trace log"
> >  res=0
> 
> I've got some additional comments regarding the fields in the code
> below, but it would be good to hear Steve comment on the "actions"
> field since his userspace tools are extremely picky about what they
> will accept.

Its not that the audit user space applications are picky, its that we have a 
coding standard that everyone needs to abide by so that any parser coded to 
the specification works. In short, we should not have spaces inside the "" 
because that can trick a naive parser. What we typically do in a situation 
like this is add a comma as a separator. But having "" means that the value 
is untrusted and subject to escaping. I don't think that is the case here. 
Output is not controlled by the user. Its a list of well known names.

> It looks like you are treating the actions as an untrusted string, which is
> good, so I suspect you are okay, but still

The function below that logs names is calling audit_log_format which does not 
handle untrusted strings. I would suggest not treating it as an untrusted 
string, but as a string with no spaces in it. 

actions=kill_process,kill_thread,errno,trace,log


> > Writing the string "log log errno trace kill_process kill_thread", which
> > is unordered and contains the log action twice, results in the same
> > 
> > value as the previous example for the actions field:
> >  type=CONFIG_CHANGE msg=audit(1524601204.365:152): pid=1704 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging actions="kill_process kill_thread errno trace log"
> >  res=0
> > 
> > No audit records are generated when reading the actions_logged sysctl.
> > 
> > Suggested-by: Steve Grubb <sgr...@redhat.com>
> > Signed-off-by: Tyler Hicks <tyhi...@canonical.com>
> > ---
> > 
> >  include/linux/audit.h |  3 +++
> >  kernel/auditsc.c  | 37 +
> >  kernel/seccomp.c  | 43 ++-
> >  3 files changed, 74 insertions(+), 9 deletions(-)
> 
> ...
> 
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 75d5b03..b311d7d 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -233,6 +233,7 @@ extern void __audit_inode_child(struct inode *parent,
> > 
> > const struct dentry *dentry,
> > const unsigned char type);
> >  
> >  extern void __audit_seccomp(unsigned long syscall, long signr, int
> >  code);
> > 
> > +extern void audit_seccomp_actions_logged(const char *names, int res);
> > 
> >  extern 

Re: [PATCH 2/3] seccomp: Audit attempts to modify the actions_logged sysctl

[Steve Grubb]

On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote:
> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks  wrote:
> > The decision to log a seccomp action will always be subject to the
> > value of the kernel.seccomp.actions_logged sysctl, even for processes
> > that are being inspected via the audit subsystem, in an upcoming patch.
> > Therefore, we need to emit an audit record on attempts at writing to the
> > actions_logged sysctl when auditing is enabled.
> > 
> > This patch updates the write handler for the actions_logged sysctl to
> > emit an audit record on attempts to write to the sysctl. Successful
> > writes to the sysctl will result in a record that includes a normalized
> > list of logged actions in the "actions" field and a "res" field equal to
> > 0. Unsuccessful writes to the sysctl will result in a record that
> > doesn't include the "actions" field and has a "res" field equal to 1.
> > 
> > Not all unsuccessful writes to the sysctl are audited. For example, an
> > audit record will not be emitted if an unprivileged process attempts to
> > open the sysctl file for reading since that access control check is not
> > part of the sysctl's write handler.
> > 
> > Below are some example audit records when writing various strings to the
> > actions_logged sysctl.
> > 
> > Writing "not-a-real-action" emits:
> >  type=CONFIG_CHANGE msg=audit(1524600971.363:119): pid=1651 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging res=1
> > 
> > Writing "kill_process kill_thread errno trace log" emits:
> >  type=CONFIG_CHANGE msg=audit(1524601023.982:131): pid=1658 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging actions="kill_process kill_thread errno trace log"
> >  res=0
> 
> I've got some additional comments regarding the fields in the code
> below, but it would be good to hear Steve comment on the "actions"
> field since his userspace tools are extremely picky about what they
> will accept.

Its not that the audit user space applications are picky, its that we have a 
coding standard that everyone needs to abide by so that any parser coded to 
the specification works. In short, we should not have spaces inside the "" 
because that can trick a naive parser. What we typically do in a situation 
like this is add a comma as a separator. But having "" means that the value 
is untrusted and subject to escaping. I don't think that is the case here. 
Output is not controlled by the user. Its a list of well known names.

> It looks like you are treating the actions as an untrusted string, which is
> good, so I suspect you are okay, but still

The function below that logs names is calling audit_log_format which does not 
handle untrusted strings. I would suggest not treating it as an untrusted 
string, but as a string with no spaces in it. 

actions=kill_process,kill_thread,errno,trace,log


> > Writing the string "log log errno trace kill_process kill_thread", which
> > is unordered and contains the log action twice, results in the same
> > 
> > value as the previous example for the actions field:
> >  type=CONFIG_CHANGE msg=audit(1524601204.365:152): pid=1704 uid=0
> >  auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
> >  op=seccomp-logging actions="kill_process kill_thread errno trace log"
> >  res=0
> > 
> > No audit records are generated when reading the actions_logged sysctl.
> > 
> > Suggested-by: Steve Grubb 
> > Signed-off-by: Tyler Hicks 
> > ---
> > 
> >  include/linux/audit.h |  3 +++
> >  kernel/auditsc.c  | 37 +
> >  kernel/seccomp.c  | 43 ++-
> >  3 files changed, 74 insertions(+), 9 deletions(-)
> 
> ...
> 
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 75d5b03..b311d7d 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -233,6 +233,7 @@ extern void __audit_inode_child(struct inode *parent,
> > 
> > const struct dentry *dentry,
> > const unsigned char type);
> >  
> >  extern void __audit_seccomp(unsigned long syscall, long signr, int
> >  code);
> > 
> > +extern void audit_seccomp_actions_logged(const char *names, int res);
> > 
> >  extern void __audit_ptrace(struct task_struct *t);
> >  
> >  st

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

[Steve Grubb]

On Tuesday, April 17, 2018 6:06:24 PM EDT Paul Moore wrote:
> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs  wrote:
> > Tie syscall information to FEATURE_CHANGE calls since it is a result of
> > user action.
> > 
> > See: https://github.com/linux-audit/audit-kernel/issues/80
> > 
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > 
> >  kernel/audit.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 8da24ef..23f125b 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1103,10 +1103,9 @@ static void audit_log_feature_change(int which,
> > u32 old_feature, u32 new_feature> 
> >  {
> >  
> > struct audit_buffer *ab;
> > 
> > -   if (audit_enabled == AUDIT_OFF)
> > +   if (!audit_enabled)
> 
> Sooo, this is an unrelated style change, why?  Looking at the rest of
> kernel/audit.c we seem to use a mix of "(!x)" and "(x == 0/CONST)" so
> why are you adding noise to this patch?
> 
> > return;
> > 
> > -
> > -   ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
> > +   ab = audit_log_start(current->audit_context, GFP_KERNEL,
> > AUDIT_FEATURE_CHANGE);
> This is the important part, and the Right Thing To Do.

This is an unexpected change. I have asked questions on the github issue 
tracker but have not gotten a satisfactory answer. Please do not merge this 
until there's agreement on this.

Thanks,
-Steve

> > if (!ab)
> > 
> > return;
> > 
> > audit_log_task_info(ab, current);
> > 
> > --
> > 1.8.3.1

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

[Steve Grubb]

On Tuesday, April 17, 2018 6:06:24 PM EDT Paul Moore wrote:
> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs  wrote:
> > Tie syscall information to FEATURE_CHANGE calls since it is a result of
> > user action.
> > 
> > See: https://github.com/linux-audit/audit-kernel/issues/80
> > 
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > 
> >  kernel/audit.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 8da24ef..23f125b 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1103,10 +1103,9 @@ static void audit_log_feature_change(int which,
> > u32 old_feature, u32 new_feature> 
> >  {
> >  
> > struct audit_buffer *ab;
> > 
> > -   if (audit_enabled == AUDIT_OFF)
> > +   if (!audit_enabled)
> 
> Sooo, this is an unrelated style change, why?  Looking at the rest of
> kernel/audit.c we seem to use a mix of "(!x)" and "(x == 0/CONST)" so
> why are you adding noise to this patch?
> 
> > return;
> > 
> > -
> > -   ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
> > +   ab = audit_log_start(current->audit_context, GFP_KERNEL,
> > AUDIT_FEATURE_CHANGE);
> This is the important part, and the Right Thing To Do.

This is an unexpected change. I have asked questions on the github issue 
tracker but have not gotten a satisfactory answer. Please do not merge this 
until there's agreement on this.

Thanks,
-Steve

> > if (!ab)
> > 
> > return;
> > 
> > audit_log_task_info(ab, current);
> > 
> > --
> > 1.8.3.1

Re: [PATCH ghak46 V1] audit: normalize MAC_STATUS record

[Steve Grubb]

On Monday, April 16, 2018 10:11:01 AM EDT Richard Guy Briggs wrote:
> On 2018-04-16 09:26, Ondrej Mosnacek wrote:
> > 2018-04-10 1:34 GMT+02:00 Richard Guy Briggs :
> > > There were two formats of the audit MAC_STATUS record, one of which was
> > > more standard than the other.  One listed enforcing status changes and
> > > the other listed enabled status changes with a non-standard label.  In
> > > addition, the record was missing information about which LSM was
> > > responsible and the operation's completion status.  While this record
> > > is
> > > only issued on success, the parser expects the res= field to be
> > > present.
> > > 
> > > old enforcing/permissive:
> > > type=MAC_STATUS msg=audit(1523312831.378:24514): enforcing=0
> > > old_enforcing=1 auid=0 ses=1 old enable/disable:
> > > type=MAC_STATUS msg=audit(1523312831.378:24514): selinux=0 auid=0 ses=1
> > > 
> > > List both sets of status and old values and add the lsm= field and the
> > > res= field.
> > > 
> > > Here is the new format:
> > > type=MAC_STATUS msg=audit(1523293828.657:891): enforcing=0
> > > old_enforcing=1 auid=0 ses=1 enabled=1 old-enabled=1 lsm=selinux res=1
> > > 
> > > This record already accompanied a SYSCALL record.
> > > 
> > > See: https://github.com/linux-audit/audit-kernel/issues/46
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > 
> > >  security/selinux/selinuxfs.c | 11 +++
> > >  1 file changed, 7 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/security/selinux/selinuxfs.c
> > > b/security/selinux/selinuxfs.c
> > > index 00eed84..00b21b2 100644
> > > --- a/security/selinux/selinuxfs.c
> > > +++ b/security/selinux/selinuxfs.c
> > > @@ -145,10 +145,11 @@ static ssize_t sel_write_enforce(struct file
> > > *file, const char __user *buf,> > 
> > > if (length)
> > > 
> > > goto out;
> > > 
> > > audit_log(current->audit_context, GFP_KERNEL,
> > > AUDIT_MAC_STATUS,
> > > 
> > > -   "enforcing=%d old_enforcing=%d auid=%u ses=%u",
> > > +   "enforcing=%d old_enforcing=%d auid=%u ses=%u"
> > > +   " enabled=%d old-enabled=%d lsm=selinux res=1",
> > 
> > This is just a tiny nit but why does "old_enforcing" use an underscore
> > and "old-enabled" a dash? Shouldn't the style be consistent across
> > fields?

Well, we have this thing called the field dictionary:

https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/
field-dictionary.csv

If a field exists, we should reuse it and follow the exact formatting for the 
value side. In this case, old_enforcing is in the dictionary. So, it should 
be used.

> Yes, but my understanding is a preference for underscore, and not to
> change existing field names.
> 
> Steve?

When you are gluing 2 words together, I prefer a dash. But, in this case we 
alreday have precedent that the field name exists, so we should reuse it.

-Steve

> > Just my two cents...
> 
> These details are worth noticing, thank you.
> 
> > > new_value, selinux_enforcing,
> > > from_kuid(_user_ns,
> > > audit_get_loginuid(current)),
> > > 
> > > -   audit_get_sessionid(current));
> > > +   audit_get_sessionid(current), selinux_enabled,
> > > selinux_enabled);> > 
> > > selinux_enforcing = new_value;
> > > if (selinux_enforcing)
> > > 
> > > avc_ss_reset(0);
> > > 
> > > @@ -272,9 +273,11 @@ static ssize_t sel_write_disable(struct file
> > > *file, const char __user *buf,> > 
> > > if (length)
> > > 
> > > goto out;
> > > 
> > > audit_log(current->audit_context, GFP_KERNEL,
> > > AUDIT_MAC_STATUS,
> > > 
> > > -   "selinux=0 auid=%u ses=%u",
> > > +   "enforcing=%d old_enforcing=%d auid=%u ses=%u"
> > > +   " enabled=%d old-enabled=%d lsm=selinux res=1",
> > > +   selinux_enforcing, selinux_enforcing,
> > 
> > ^ also here
> > 
> > > from_kuid(_user_ns,
> > > audit_get_loginuid(current)),
> > > 
> > > -   audit_get_sessionid(current));
> > > +   audit_get_sessionid(current), 0, 1);
> > > 
> > > }
> > > 
> > > length = count;
> > 
> > Ondrej Mosnacek 
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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
> 
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH ghak46 V1] audit: normalize MAC_STATUS record

[Steve Grubb]

On Monday, April 16, 2018 10:11:01 AM EDT Richard Guy Briggs wrote:
> On 2018-04-16 09:26, Ondrej Mosnacek wrote:
> > 2018-04-10 1:34 GMT+02:00 Richard Guy Briggs :
> > > There were two formats of the audit MAC_STATUS record, one of which was
> > > more standard than the other.  One listed enforcing status changes and
> > > the other listed enabled status changes with a non-standard label.  In
> > > addition, the record was missing information about which LSM was
> > > responsible and the operation's completion status.  While this record
> > > is
> > > only issued on success, the parser expects the res= field to be
> > > present.
> > > 
> > > old enforcing/permissive:
> > > type=MAC_STATUS msg=audit(1523312831.378:24514): enforcing=0
> > > old_enforcing=1 auid=0 ses=1 old enable/disable:
> > > type=MAC_STATUS msg=audit(1523312831.378:24514): selinux=0 auid=0 ses=1
> > > 
> > > List both sets of status and old values and add the lsm= field and the
> > > res= field.
> > > 
> > > Here is the new format:
> > > type=MAC_STATUS msg=audit(1523293828.657:891): enforcing=0
> > > old_enforcing=1 auid=0 ses=1 enabled=1 old-enabled=1 lsm=selinux res=1
> > > 
> > > This record already accompanied a SYSCALL record.
> > > 
> > > See: https://github.com/linux-audit/audit-kernel/issues/46
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > 
> > >  security/selinux/selinuxfs.c | 11 +++
> > >  1 file changed, 7 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/security/selinux/selinuxfs.c
> > > b/security/selinux/selinuxfs.c
> > > index 00eed84..00b21b2 100644
> > > --- a/security/selinux/selinuxfs.c
> > > +++ b/security/selinux/selinuxfs.c
> > > @@ -145,10 +145,11 @@ static ssize_t sel_write_enforce(struct file
> > > *file, const char __user *buf,> > 
> > > if (length)
> > > 
> > > goto out;
> > > 
> > > audit_log(current->audit_context, GFP_KERNEL,
> > > AUDIT_MAC_STATUS,
> > > 
> > > -   "enforcing=%d old_enforcing=%d auid=%u ses=%u",
> > > +   "enforcing=%d old_enforcing=%d auid=%u ses=%u"
> > > +   " enabled=%d old-enabled=%d lsm=selinux res=1",
> > 
> > This is just a tiny nit but why does "old_enforcing" use an underscore
> > and "old-enabled" a dash? Shouldn't the style be consistent across
> > fields?

Well, we have this thing called the field dictionary:

https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/
field-dictionary.csv

If a field exists, we should reuse it and follow the exact formatting for the 
value side. In this case, old_enforcing is in the dictionary. So, it should 
be used.

> Yes, but my understanding is a preference for underscore, and not to
> change existing field names.
> 
> Steve?

When you are gluing 2 words together, I prefer a dash. But, in this case we 
alreday have precedent that the field name exists, so we should reuse it.

-Steve

> > Just my two cents...
> 
> These details are worth noticing, thank you.
> 
> > > new_value, selinux_enforcing,
> > > from_kuid(_user_ns,
> > > audit_get_loginuid(current)),
> > > 
> > > -   audit_get_sessionid(current));
> > > +   audit_get_sessionid(current), selinux_enabled,
> > > selinux_enabled);> > 
> > > selinux_enforcing = new_value;
> > > if (selinux_enforcing)
> > > 
> > > avc_ss_reset(0);
> > > 
> > > @@ -272,9 +273,11 @@ static ssize_t sel_write_disable(struct file
> > > *file, const char __user *buf,> > 
> > > if (length)
> > > 
> > > goto out;
> > > 
> > > audit_log(current->audit_context, GFP_KERNEL,
> > > AUDIT_MAC_STATUS,
> > > 
> > > -   "selinux=0 auid=%u ses=%u",
> > > +   "enforcing=%d old_enforcing=%d auid=%u ses=%u"
> > > +   " enabled=%d old-enabled=%d lsm=selinux res=1",
> > > +   selinux_enforcing, selinux_enforcing,
> > 
> > ^ also here
> > 
> > > from_kuid(_user_ns,
> > > audit_get_loginuid(current)),
> > > 
> > > -   audit_get_sessionid(current));
> > > +   audit_get_sessionid(current), 0, 1);
> > > 
> > > }
> > > 
> > > length = count;
> > 
> > Ondrej Mosnacek 
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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
> 
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Tuesday, March 13, 2018 8:35:44 PM EDT Andy Lutomirski wrote:
> On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina  wrote:
> > On Wed, 14 Mar 2018, Andy Lutomirski wrote:
> >> > Yes...I wished I was in on the beginning of this discussion. Here's
> >> > the
> >> > problem. We need all tasks auditable unless specifically dismissed as
> >> > uninteresting. This would be a task,never rule.
> >> > 
> >> > The way we look at it, is if it boots with audit=1, then we know
> >> > auditd
> >> > is expected to run at some point. So, we need all tasks to stay
> >> > auditable. If they weren't and auditd enabled auditing, then we'd need
> >> > to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
> >> > process in the system. It was decided that this is too ugly.
> >> 
> >> When was that decided?  That's what this patch does.
> > 
> > I'd like to see some more justification as well.
> > 
> > Namely, if I compare "setting TIF_AUDIT_SYSCALL for every process on a
> > need-to-be-so basis" to "we always go through the slow path and
> > pessimistically assume that audit is enabled and has reasonable ruleset
> > loaded", I have my own (different) opinion of what is too ugly.
> 
> Me too.
> 
> That being said, on re-review of my old code, I think that
> audit_dec_n_rules() may be the wrong approach.  It may be better to
> leave TIF_AUDIT_SYSCALL set but to make the audit code itself clear
> the flag the next time through.  That way we don't end up with a
> partially filled in syscall audit record that never gets consumed if
> we clear TIF_AUDIT_SYSCALL in the middle of a syscall.

So what happened when auditd is being restarted due to system update? Its 
possible to have no auditd, no rules, and audit_enabled == 0. But its getting 
ready to start a new auditd, enable audit, and load rules. In this case, we 
expect tasks already dismissed by task filter to stay dismissed because the 
task filter only runs at fork time.

For example, suppose httpd is not desired to be audited. The admin sets up a 
task rule that sets it to never for httpd. The rule triggers at fork and 
marks it inauditable. Would this patch cause httpd to suddenly become 
auditable again during an auditd restart?

Rather than play run time games which is ultimately racey and prone to 
missing something, what about the approach of controlling this from a boot 
variable and letting user space see an error should auditing try to do its 
normal thing when its not wanted? This way auditd can exit and there aren't 
any races.

-Steve

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Tuesday, March 13, 2018 8:35:44 PM EDT Andy Lutomirski wrote:
> On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina  wrote:
> > On Wed, 14 Mar 2018, Andy Lutomirski wrote:
> >> > Yes...I wished I was in on the beginning of this discussion. Here's
> >> > the
> >> > problem. We need all tasks auditable unless specifically dismissed as
> >> > uninteresting. This would be a task,never rule.
> >> > 
> >> > The way we look at it, is if it boots with audit=1, then we know
> >> > auditd
> >> > is expected to run at some point. So, we need all tasks to stay
> >> > auditable. If they weren't and auditd enabled auditing, then we'd need
> >> > to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
> >> > process in the system. It was decided that this is too ugly.
> >> 
> >> When was that decided?  That's what this patch does.
> > 
> > I'd like to see some more justification as well.
> > 
> > Namely, if I compare "setting TIF_AUDIT_SYSCALL for every process on a
> > need-to-be-so basis" to "we always go through the slow path and
> > pessimistically assume that audit is enabled and has reasonable ruleset
> > loaded", I have my own (different) opinion of what is too ugly.
> 
> Me too.
> 
> That being said, on re-review of my old code, I think that
> audit_dec_n_rules() may be the wrong approach.  It may be better to
> leave TIF_AUDIT_SYSCALL set but to make the audit code itself clear
> the flag the next time through.  That way we don't end up with a
> partially filled in syscall audit record that never gets consumed if
> we clear TIF_AUDIT_SYSCALL in the middle of a syscall.

So what happened when auditd is being restarted due to system update? Its 
possible to have no auditd, no rules, and audit_enabled == 0. But its getting 
ready to start a new auditd, enable audit, and load rules. In this case, we 
expect tasks already dismissed by task filter to stay dismissed because the 
task filter only runs at fork time.

For example, suppose httpd is not desired to be audited. The admin sets up a 
task rule that sets it to never for httpd. The rule triggers at fork and 
marks it inauditable. Would this patch cause httpd to suddenly become 
auditable again during an auditd restart?

Rather than play run time games which is ultimately racey and prone to 
missing something, what about the approach of controlling this from a boot 
variable and letting user space see an error should auditing try to do its 
normal thing when its not wanted? This way auditd can exit and there aren't 
any races.

-Steve

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Tuesday, March 13, 2018 8:28:57 PM EDT Jiri Kosina wrote:
> On Wed, 14 Mar 2018, Andy Lutomirski wrote:
> > > Yes...I wished I was in on the beginning of this discussion. Here's the
> > > problem. We need all tasks auditable unless specifically dismissed as
> > > uninteresting. This would be a task,never rule.
> > > 
> > > The way we look at it, is if it boots with audit=1, then we know auditd
> > > is expected to run at some point. So, we need all tasks to stay
> > > auditable. If they weren't and auditd enabled auditing, then we'd need
> > > to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
> > > process in the system. It was decided that this is too ugly.
> > 
> > When was that decided?  That's what this patch does.
> 
> I'd like to see some more justification as well.

There was some discussion about removing the flag here:
https://www.redhat.com/archives/linux-audit/2007-October/msg00053.html

-Steve

> Namely, if I compare "setting TIF_AUDIT_SYSCALL for every process on a
> need-to-be-so basis" to "we always go through the slow path and
> pessimistically assume that audit is enabled and has reasonable ruleset
> loaded", I have my own (different) opinion of what is too ugly.

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Tuesday, March 13, 2018 8:28:57 PM EDT Jiri Kosina wrote:
> On Wed, 14 Mar 2018, Andy Lutomirski wrote:
> > > Yes...I wished I was in on the beginning of this discussion. Here's the
> > > problem. We need all tasks auditable unless specifically dismissed as
> > > uninteresting. This would be a task,never rule.
> > > 
> > > The way we look at it, is if it boots with audit=1, then we know auditd
> > > is expected to run at some point. So, we need all tasks to stay
> > > auditable. If they weren't and auditd enabled auditing, then we'd need
> > > to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
> > > process in the system. It was decided that this is too ugly.
> > 
> > When was that decided?  That's what this patch does.
> 
> I'd like to see some more justification as well.

There was some discussion about removing the flag here:
https://www.redhat.com/archives/linux-audit/2007-October/msg00053.html

-Steve

> Namely, if I compare "setting TIF_AUDIT_SYSCALL for every process on a
> need-to-be-so basis" to "we always go through the slow path and
> pessimistically assume that audit is enabled and has reasonable ruleset
> loaded", I have my own (different) opinion of what is too ugly.

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Tue, 13 Mar 2018 06:52:51 -0400
Richard Guy Briggs <r...@redhat.com> wrote:

> On 2018-03-13 11:38, Steve Grubb wrote:
> > On Tue, 13 Mar 2018 06:11:08 -0400
> > Richard Guy Briggs <r...@redhat.com> wrote:
> >   
> > > On 2018-03-13 09:35, Steve Grubb wrote:  
> > > > On Mon, 12 Mar 2018 11:52:56 -0400
> > > > Richard Guy Briggs <r...@redhat.com> wrote:
> > > > 
> > > > > On 2018-03-12 11:53, Paul Moore wrote:
> > > > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> > > > > > <r...@redhat.com> wrote:  
> > > > > > > On 2018-03-12 11:12, Paul Moore wrote:  
> > > > > > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > > > > > >> <r...@redhat.com> wrote:  
> > > > > > >> > Audit link denied events for symlinks had duplicate
> > > > > > >> > PATH records rather than just updating the existing
> > > > > > >> > PATH record. Update the symlink's PATH record with the
> > > > > > >> > current dentry and inode information.
> > > > > > >> >
> > > > > > >> > See:
> > > > > > >> > https://github.com/linux-audit/audit-kernel/issues/21
> > > > > > >> > Signed-off-by: Richard Guy Briggs <r...@redhat.com> ---
> > > > > > >> >  fs/namei.c | 1 +
> > > > > > >> >  1 file changed, 1 insertion(+)  
> > > > > > >>
> > > > > > >> Why didn't you include this in patch 4/4 like I asked
> > > > > > >> during the previous review?  
> > > > > > >
> > > > > > > Please see the last comment of:
> > > > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html
> > > > > > >   
> > > > > > 
> > > > > > Yes, I just saw that ... I hadn't seen your replies on the
> > > > > > v1 patches until I had finished reviewing v2.  I just
> > > > > > replied to that mail in the v1 thread, but basically you
> > > > > > need to figure out what is necessary here and let us know.
> > > > > > If I have to figure it out it likely isn't going to get
> > > > > > done with enough soak time prior to the upcoming merge
> > > > > > window.  
> > > > > 
> > > > > Steve?  I was hoping you could chime in here.
> > > > 
> > > > If the CWD record will always be the same as the PARENT record,
> > > > then we do not need the parent record. Duplicate information is
> > > > bad. Like all the duplicate SYSCALL information.
> > > 
> > > The CWD record could be different from the PARENT record, since I
> > > could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test.
> > > Does the parent record even matter since it might not be a
> > > directory operation like creat, unlink or rename?  
> > 
> > There's 2 issues. One is creating the path if what we have is
> > relative. In this situation CWD should be enough. But if the
> > question is whether the PARENT directory should be included...what
> > if the PARENT permissions do not allow the successful name
> > resolution? In that case we might only get a PARENT record no? In
> > that case we would need it.  
> 
> I think in the case of symlink creation, normal file create code path
> would be in effect, and would properly log parent and symlink source
> file paths (if a rule to log it was in effect) which is not something
> that would trigger a symlink link denied error.  Symlink link denied
> happens only when trying to actually follow the link before
> resolving the target path of a read/write/exec of the symlink target.
> 
> If the parent permissions of the link's target don't allow successful
> name resolution then the symlink link denied condition isn't met, but
> rather any other rule that applies to the target path.

Then I guess the PARENT record is not needed.

-Steve

> > > > > I'd just include it for completeness unless Steve thinks it
> > > > > will stand on its own and doesn't want the overhead.
> > > > > 
> > > > > > >> > diff --git a/fs/namei.c b/fs/namei.c
> > > > > > >> > index 50d2533..00f5041 100644
> > > > > > >> > --- a/fs/namei.c
> > > > > > >> > +++ b/fs/namei.c
> > > > > > >> > @@ -945,6 +945,7 @@ static inline int
> > > > > > >> > may_follow_link(struct nameidata *nd) if (nd->flags &
> > > > > > >> > LOOKUP_RCU) return -ECHILD;
> > > > > > >> >
> > > > > > >> > +   audit_inode(nd->name,
> > > > > > >> > nd->stack[0].link.dentry, 0);
> > > > > > >> > audit_log_link_denied("follow_link",
> > > > > > >> > >stack[0].link); return -EACCES; }  
> > > > > > >>
> > > > > > >> paul moore  
> > > > > > >
> > > > > > > - RGB  
> > > > > > 
> > > > > > paul moore  
> > > > > 
> > > > > - RGB
> > > 
> > > - RGB
> > > 
> > > --
> > > Richard Guy Briggs <r...@redhat.com>
> > > 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  
> >   
> 
> - RGB
> 
> --
> Richard Guy Briggs <r...@redhat.com>
> 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

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Tue, 13 Mar 2018 06:52:51 -0400
Richard Guy Briggs  wrote:

> On 2018-03-13 11:38, Steve Grubb wrote:
> > On Tue, 13 Mar 2018 06:11:08 -0400
> > Richard Guy Briggs  wrote:
> >   
> > > On 2018-03-13 09:35, Steve Grubb wrote:  
> > > > On Mon, 12 Mar 2018 11:52:56 -0400
> > > > Richard Guy Briggs  wrote:
> > > > 
> > > > > On 2018-03-12 11:53, Paul Moore wrote:
> > > > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> > > > > >  wrote:  
> > > > > > > On 2018-03-12 11:12, Paul Moore wrote:  
> > > > > > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > > > > > >>  wrote:  
> > > > > > >> > Audit link denied events for symlinks had duplicate
> > > > > > >> > PATH records rather than just updating the existing
> > > > > > >> > PATH record. Update the symlink's PATH record with the
> > > > > > >> > current dentry and inode information.
> > > > > > >> >
> > > > > > >> > See:
> > > > > > >> > https://github.com/linux-audit/audit-kernel/issues/21
> > > > > > >> > Signed-off-by: Richard Guy Briggs  ---
> > > > > > >> >  fs/namei.c | 1 +
> > > > > > >> >  1 file changed, 1 insertion(+)  
> > > > > > >>
> > > > > > >> Why didn't you include this in patch 4/4 like I asked
> > > > > > >> during the previous review?  
> > > > > > >
> > > > > > > Please see the last comment of:
> > > > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html
> > > > > > >   
> > > > > > 
> > > > > > Yes, I just saw that ... I hadn't seen your replies on the
> > > > > > v1 patches until I had finished reviewing v2.  I just
> > > > > > replied to that mail in the v1 thread, but basically you
> > > > > > need to figure out what is necessary here and let us know.
> > > > > > If I have to figure it out it likely isn't going to get
> > > > > > done with enough soak time prior to the upcoming merge
> > > > > > window.  
> > > > > 
> > > > > Steve?  I was hoping you could chime in here.
> > > > 
> > > > If the CWD record will always be the same as the PARENT record,
> > > > then we do not need the parent record. Duplicate information is
> > > > bad. Like all the duplicate SYSCALL information.
> > > 
> > > The CWD record could be different from the PARENT record, since I
> > > could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test.
> > > Does the parent record even matter since it might not be a
> > > directory operation like creat, unlink or rename?  
> > 
> > There's 2 issues. One is creating the path if what we have is
> > relative. In this situation CWD should be enough. But if the
> > question is whether the PARENT directory should be included...what
> > if the PARENT permissions do not allow the successful name
> > resolution? In that case we might only get a PARENT record no? In
> > that case we would need it.  
> 
> I think in the case of symlink creation, normal file create code path
> would be in effect, and would properly log parent and symlink source
> file paths (if a rule to log it was in effect) which is not something
> that would trigger a symlink link denied error.  Symlink link denied
> happens only when trying to actually follow the link before
> resolving the target path of a read/write/exec of the symlink target.
> 
> If the parent permissions of the link's target don't allow successful
> name resolution then the symlink link denied condition isn't met, but
> rather any other rule that applies to the target path.

Then I guess the PARENT record is not needed.

-Steve

> > > > > I'd just include it for completeness unless Steve thinks it
> > > > > will stand on its own and doesn't want the overhead.
> > > > > 
> > > > > > >> > diff --git a/fs/namei.c b/fs/namei.c
> > > > > > >> > index 50d2533..00f5041 100644
> > > > > > >> > --- a/fs/namei.c
> > > > > > >> > +++ b/fs/namei.c
> > > > > > >> > @@ -945,6 +945,7 @@ static inline int
> > > > > > >> > may_follow_link(struct nameidata *nd) if (nd->flags &
> > > > > > >> > LOOKUP_RCU) return -ECHILD;
> > > > > > >> >
> > > > > > >> > +   audit_inode(nd->name,
> > > > > > >> > nd->stack[0].link.dentry, 0);
> > > > > > >> > audit_log_link_denied("follow_link",
> > > > > > >> > >stack[0].link); return -EACCES; }  
> > > > > > >>
> > > > > > >> paul moore  
> > > > > > >
> > > > > > > - RGB  
> > > > > > 
> > > > > > paul moore  
> > > > > 
> > > > > - RGB
> > > 
> > > - RGB
> > > 
> > > --
> > > Richard Guy Briggs 
> > > 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  
> >   
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Tue, 13 Mar 2018 06:11:08 -0400
Richard Guy Briggs <r...@redhat.com> wrote:

> On 2018-03-13 09:35, Steve Grubb wrote:
> > On Mon, 12 Mar 2018 11:52:56 -0400
> > Richard Guy Briggs <r...@redhat.com> wrote:
> >   
> > > On 2018-03-12 11:53, Paul Moore wrote:  
> > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> > > > <r...@redhat.com> wrote:
> > > > > On 2018-03-12 11:12, Paul Moore wrote:
> > > > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > > > >> <r...@redhat.com> wrote:
> > > > >> > Audit link denied events for symlinks had duplicate PATH
> > > > >> > records rather than just updating the existing PATH record.
> > > > >> > Update the symlink's PATH record with the current dentry
> > > > >> > and inode information.
> > > > >> >
> > > > >> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > > > >> > Signed-off-by: Richard Guy Briggs <r...@redhat.com>
> > > > >> > ---
> > > > >> >  fs/namei.c | 1 +
> > > > >> >  1 file changed, 1 insertion(+)
> > > > >>
> > > > >> Why didn't you include this in patch 4/4 like I asked during
> > > > >> the previous review?
> > > > >
> > > > > Please see the last comment of:
> > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html  
> > > > >   
> > > > 
> > > > Yes, I just saw that ... I hadn't seen your replies on the v1
> > > > patches until I had finished reviewing v2.  I just replied to
> > > > that mail in the v1 thread, but basically you need to figure
> > > > out what is necessary here and let us know.  If I have to
> > > > figure it out it likely isn't going to get done with enough
> > > > soak time prior to the upcoming merge window.
> > > 
> > > Steve?  I was hoping you could chime in here.  
> > 
> > If the CWD record will always be the same as the PARENT record,
> > then we do not need the parent record. Duplicate information is
> > bad. Like all the duplicate SYSCALL information.  
> 
> The CWD record could be different from the PARENT record, since I
> could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test.
> Does the parent record even matter since it might not be a directory
> operation like creat, unlink or rename?

There's 2 issues. One is creating the path if what we have is relative.
In this situation CWD should be enough. But if the question is whether
the PARENT directory should be included...what if the PARENT
permissions do not allow the successful name resolution? In that case
we might only get a PARENT record no? In that case we would need it.

-Steve

> > > I'd just include it for completeness unless Steve thinks it will
> > > stand on its own and doesn't want the overhead.
> > >   
> > > > >> > diff --git a/fs/namei.c b/fs/namei.c
> > > > >> > index 50d2533..00f5041 100644
> > > > >> > --- a/fs/namei.c
> > > > >> > +++ b/fs/namei.c
> > > > >> > @@ -945,6 +945,7 @@ static inline int
> > > > >> > may_follow_link(struct nameidata *nd) if (nd->flags &
> > > > >> > LOOKUP_RCU) return -ECHILD;
> > > > >> >
> > > > >> > +   audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > > > >> > audit_log_link_denied("follow_link",
> > > > >> > >stack[0].link); return -EACCES;
> > > > >> >  }
> > > > >>
> > > > >> paul moore
> > > > >
> > > > > - RGB
> > > > 
> > > > paul moore
> > > 
> > > - RGB  
> 
> - RGB
> 
> --
> Richard Guy Briggs <r...@redhat.com>
> 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

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Tue, 13 Mar 2018 06:11:08 -0400
Richard Guy Briggs  wrote:

> On 2018-03-13 09:35, Steve Grubb wrote:
> > On Mon, 12 Mar 2018 11:52:56 -0400
> > Richard Guy Briggs  wrote:
> >   
> > > On 2018-03-12 11:53, Paul Moore wrote:  
> > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> > > >  wrote:
> > > > > On 2018-03-12 11:12, Paul Moore wrote:
> > > > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > > > >>  wrote:
> > > > >> > Audit link denied events for symlinks had duplicate PATH
> > > > >> > records rather than just updating the existing PATH record.
> > > > >> > Update the symlink's PATH record with the current dentry
> > > > >> > and inode information.
> > > > >> >
> > > > >> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > > > >> > Signed-off-by: Richard Guy Briggs 
> > > > >> > ---
> > > > >> >  fs/namei.c | 1 +
> > > > >> >  1 file changed, 1 insertion(+)
> > > > >>
> > > > >> Why didn't you include this in patch 4/4 like I asked during
> > > > >> the previous review?
> > > > >
> > > > > Please see the last comment of:
> > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html  
> > > > >   
> > > > 
> > > > Yes, I just saw that ... I hadn't seen your replies on the v1
> > > > patches until I had finished reviewing v2.  I just replied to
> > > > that mail in the v1 thread, but basically you need to figure
> > > > out what is necessary here and let us know.  If I have to
> > > > figure it out it likely isn't going to get done with enough
> > > > soak time prior to the upcoming merge window.
> > > 
> > > Steve?  I was hoping you could chime in here.  
> > 
> > If the CWD record will always be the same as the PARENT record,
> > then we do not need the parent record. Duplicate information is
> > bad. Like all the duplicate SYSCALL information.  
> 
> The CWD record could be different from the PARENT record, since I
> could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test.
> Does the parent record even matter since it might not be a directory
> operation like creat, unlink or rename?

There's 2 issues. One is creating the path if what we have is relative.
In this situation CWD should be enough. But if the question is whether
the PARENT directory should be included...what if the PARENT
permissions do not allow the successful name resolution? In that case
we might only get a PARENT record no? In that case we would need it.

-Steve

> > > I'd just include it for completeness unless Steve thinks it will
> > > stand on its own and doesn't want the overhead.
> > >   
> > > > >> > diff --git a/fs/namei.c b/fs/namei.c
> > > > >> > index 50d2533..00f5041 100644
> > > > >> > --- a/fs/namei.c
> > > > >> > +++ b/fs/namei.c
> > > > >> > @@ -945,6 +945,7 @@ static inline int
> > > > >> > may_follow_link(struct nameidata *nd) if (nd->flags &
> > > > >> > LOOKUP_RCU) return -ECHILD;
> > > > >> >
> > > > >> > +   audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > > > >> > audit_log_link_denied("follow_link",
> > > > >> > >stack[0].link); return -EACCES;
> > > > >> >  }
> > > > >>
> > > > >> paul moore
> > > > >
> > > > > - RGB
> > > > 
> > > > paul moore
> > > 
> > > - RGB  
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Mon, 12 Mar 2018 11:52:56 -0400
Richard Guy Briggs  wrote:

> On 2018-03-12 11:53, Paul Moore wrote:
> > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> >  wrote:  
> > > On 2018-03-12 11:12, Paul Moore wrote:  
> > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > >>  wrote:  
> > >> > Audit link denied events for symlinks had duplicate PATH
> > >> > records rather than just updating the existing PATH record.
> > >> > Update the symlink's PATH record with the current dentry and
> > >> > inode information.
> > >> >
> > >> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > >> > Signed-off-by: Richard Guy Briggs 
> > >> > ---
> > >> >  fs/namei.c | 1 +
> > >> >  1 file changed, 1 insertion(+)  
> > >>
> > >> Why didn't you include this in patch 4/4 like I asked during the
> > >> previous review?  
> > >
> > > Please see the last comment of:
> > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html  
> > 
> > Yes, I just saw that ... I hadn't seen your replies on the v1
> > patches until I had finished reviewing v2.  I just replied to that
> > mail in the v1 thread, but basically you need to figure out what is
> > necessary here and let us know.  If I have to figure it out it
> > likely isn't going to get done with enough soak time prior to the
> > upcoming merge window.  
> 
> Steve?  I was hoping you could chime in here.

If the CWD record will always be the same as the PARENT record, then we
do not need the parent record. Duplicate information is bad. Like all
the duplicate SYSCALL information.

-Steve


> I'd just include it for completeness unless Steve thinks it will stand
> on its own and doesn't want the overhead.
> 
> > >> > diff --git a/fs/namei.c b/fs/namei.c
> > >> > index 50d2533..00f5041 100644
> > >> > --- a/fs/namei.c
> > >> > +++ b/fs/namei.c
> > >> > @@ -945,6 +945,7 @@ static inline int may_follow_link(struct
> > >> > nameidata *nd) if (nd->flags & LOOKUP_RCU)
> > >> > return -ECHILD;
> > >> >
> > >> > +   audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > >> > audit_log_link_denied("follow_link",
> > >> > >stack[0].link); return -EACCES;
> > >> >  }  
> > >>
> > >> paul moore  
> > >
> > > - RGB  
> > 
> > paul moore  
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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
> 
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

[Steve Grubb]

On Mon, 12 Mar 2018 11:52:56 -0400
Richard Guy Briggs  wrote:

> On 2018-03-12 11:53, Paul Moore wrote:
> > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> >  wrote:  
> > > On 2018-03-12 11:12, Paul Moore wrote:  
> > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > >>  wrote:  
> > >> > Audit link denied events for symlinks had duplicate PATH
> > >> > records rather than just updating the existing PATH record.
> > >> > Update the symlink's PATH record with the current dentry and
> > >> > inode information.
> > >> >
> > >> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > >> > Signed-off-by: Richard Guy Briggs 
> > >> > ---
> > >> >  fs/namei.c | 1 +
> > >> >  1 file changed, 1 insertion(+)  
> > >>
> > >> Why didn't you include this in patch 4/4 like I asked during the
> > >> previous review?  
> > >
> > > Please see the last comment of:
> > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html  
> > 
> > Yes, I just saw that ... I hadn't seen your replies on the v1
> > patches until I had finished reviewing v2.  I just replied to that
> > mail in the v1 thread, but basically you need to figure out what is
> > necessary here and let us know.  If I have to figure it out it
> > likely isn't going to get done with enough soak time prior to the
> > upcoming merge window.  
> 
> Steve?  I was hoping you could chime in here.

If the CWD record will always be the same as the PARENT record, then we
do not need the parent record. Duplicate information is bad. Like all
the duplicate SYSCALL information.

-Steve


> I'd just include it for completeness unless Steve thinks it will stand
> on its own and doesn't want the overhead.
> 
> > >> > diff --git a/fs/namei.c b/fs/namei.c
> > >> > index 50d2533..00f5041 100644
> > >> > --- a/fs/namei.c
> > >> > +++ b/fs/namei.c
> > >> > @@ -945,6 +945,7 @@ static inline int may_follow_link(struct
> > >> > nameidata *nd) if (nd->flags & LOOKUP_RCU)
> > >> > return -ECHILD;
> > >> >
> > >> > +   audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > >> > audit_log_link_denied("follow_link",
> > >> > >stack[0].link); return -EACCES;
> > >> >  }  
> > >>
> > >> paul moore  
> > >
> > > - RGB  
> > 
> > paul moore  
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> 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
> 
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH ghak21 V2 0/4] audit: address ANOM_LINK excess records

[Steve Grubb]

On Mon, 12 Mar 2018 02:31:16 -0400
Richard Guy Briggs  wrote:

> Audit link denied events were being unexpectedly produced in a
> disjoint way when audit was disabled, and when they were expected,
> there were duplicate PATH records.  This patchset addresses both
> issues for symlinks and hardlinks.
> 
> This was introduced with
>   commit b24a30a7305418ff138ff51776fc555ec57c011a
>   ("audit: fix event coverage of AUDIT_ANOM_LINK")
>   commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc
>   ("fs: add link restriction audit reporting")
> 
> Here are the resulting events:
> 
> symlink:
> type=PROCTITLE msg=audit(03/12/2018 02:21:49.578:310) :
> proctitle=ls ./my-passwd type=PATH msg=audit(03/12/2018
> 02:21:49.578:310) : item=1 name=/tmp/ inode=13529 dev=00:27
> mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(03/12/2018
> 02:21:49.578:310) : item=0 name=./my-passwd inode=17090 dev=00:27
> mode=link,777 ouid=rgb ogid=rgb rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(03/12/2018
> 02:21:49.578:310) : cwd=/tmp type=SYSCALL msg=audit(03/12/2018
> 02:21:49.578:310) : arch=x86_64 syscall=stat success=no
> exit=EACCES(Permission denied) a0=0x7ffd79950dda a1=0x563f658a03c8
> a2=0x563f658a03c8 a3=0x79950d00 items=2 ppid=552 pid=629 auid=root
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=ttyS0 ses=1 comm=ls exe=/usr/bin/ls
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(03/12/2018 02:21:49.578:310) :
> op=follow_link ppid=552 pid=629 auid=root uid=root gid=root euid=root
> suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1
> comm=ls exe=/usr/bin/ls

So, if we now only emit the ANOM_LINK event when audit is enabled, we
should get rid of all the duplicate information in that record. The
SYSCALL record has all that information.

-Steve

> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
>  hardlink: type=PROCTITLE msg=audit(03/12/2018
> 02:24:39.813:314) : proctitle=ln test test-ln type=PATH
> msg=audit(03/12/2018 02:24:39.813:314) : item=1 name=/tmp inode=13529
> dev=00:27 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(03/12/2018
> 02:24:39.813:314) : item=0 name=test inode=18112 dev=00:27
> mode=file,700 ouid=root ogid=root rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(03/12/2018
> 02:24:39.813:314) : cwd=/tmp type=SYSCALL msg=audit(03/12/2018
> 02:24:39.813:314) : arch=x86_64 syscall=linkat success=no
> exit=EPERM(Operation not permitted) a0=0xff9c a1=0x7ffccba77629
> a2=0xff9c a3=0x7ffccba7762e items=2 ppid=605 pid=638 auid=rgb
> uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb sgid=rgb
> fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(03/12/2018 02:24:39.813:314) : op=linkat
> ppid=605 pid=638 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb
> egid=rgb sgid=rgb fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 
> 
> See: https://github.com/linux-audit/audit-kernel/issues/21
> See also: https://github.com/linux-audit/audit-kernel/issues/51
> 
> Richard Guy Briggs (4):
>   audit: make ANOM_LINK obey audit_enabled and audit_dummy_context
>   audit: link denied should not directly generate PATH record
>   audit: add refused symlink to audit_names
>   audit: add parent of refused symlink to audit_names
> 
>  fs/namei.c|  5 +++--
>  include/linux/audit.h |  9 +
>  kernel/audit.c| 43
> --- 3 files changed, 40
> insertions(+), 17 deletions(-)
> 

Re: [PATCH ghak21 V2 0/4] audit: address ANOM_LINK excess records

[Steve Grubb]

On Mon, 12 Mar 2018 02:31:16 -0400
Richard Guy Briggs  wrote:

> Audit link denied events were being unexpectedly produced in a
> disjoint way when audit was disabled, and when they were expected,
> there were duplicate PATH records.  This patchset addresses both
> issues for symlinks and hardlinks.
> 
> This was introduced with
>   commit b24a30a7305418ff138ff51776fc555ec57c011a
>   ("audit: fix event coverage of AUDIT_ANOM_LINK")
>   commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc
>   ("fs: add link restriction audit reporting")
> 
> Here are the resulting events:
> 
> symlink:
> type=PROCTITLE msg=audit(03/12/2018 02:21:49.578:310) :
> proctitle=ls ./my-passwd type=PATH msg=audit(03/12/2018
> 02:21:49.578:310) : item=1 name=/tmp/ inode=13529 dev=00:27
> mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(03/12/2018
> 02:21:49.578:310) : item=0 name=./my-passwd inode=17090 dev=00:27
> mode=link,777 ouid=rgb ogid=rgb rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(03/12/2018
> 02:21:49.578:310) : cwd=/tmp type=SYSCALL msg=audit(03/12/2018
> 02:21:49.578:310) : arch=x86_64 syscall=stat success=no
> exit=EACCES(Permission denied) a0=0x7ffd79950dda a1=0x563f658a03c8
> a2=0x563f658a03c8 a3=0x79950d00 items=2 ppid=552 pid=629 auid=root
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=ttyS0 ses=1 comm=ls exe=/usr/bin/ls
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(03/12/2018 02:21:49.578:310) :
> op=follow_link ppid=552 pid=629 auid=root uid=root gid=root euid=root
> suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1
> comm=ls exe=/usr/bin/ls

So, if we now only emit the ANOM_LINK event when audit is enabled, we
should get rid of all the duplicate information in that record. The
SYSCALL record has all that information.

-Steve

> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
>  hardlink: type=PROCTITLE msg=audit(03/12/2018
> 02:24:39.813:314) : proctitle=ln test test-ln type=PATH
> msg=audit(03/12/2018 02:24:39.813:314) : item=1 name=/tmp inode=13529
> dev=00:27 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(03/12/2018
> 02:24:39.813:314) : item=0 name=test inode=18112 dev=00:27
> mode=file,700 ouid=root ogid=root rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(03/12/2018
> 02:24:39.813:314) : cwd=/tmp type=SYSCALL msg=audit(03/12/2018
> 02:24:39.813:314) : arch=x86_64 syscall=linkat success=no
> exit=EPERM(Operation not permitted) a0=0xff9c a1=0x7ffccba77629
> a2=0xff9c a3=0x7ffccba7762e items=2 ppid=605 pid=638 auid=rgb
> uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb sgid=rgb
> fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(03/12/2018 02:24:39.813:314) : op=linkat
> ppid=605 pid=638 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb
> egid=rgb sgid=rgb fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no 
> 
> See: https://github.com/linux-audit/audit-kernel/issues/21
> See also: https://github.com/linux-audit/audit-kernel/issues/51
> 
> Richard Guy Briggs (4):
>   audit: make ANOM_LINK obey audit_enabled and audit_dummy_context
>   audit: link denied should not directly generate PATH record
>   audit: add refused symlink to audit_names
>   audit: add parent of refused symlink to audit_names
> 
>  fs/namei.c|  5 +++--
>  include/linux/audit.h |  9 +
>  kernel/audit.c| 43
> --- 3 files changed, 40
> insertions(+), 17 deletions(-)
> 

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Wed, 7 Mar 2018 18:43:42 -0500
Paul Moore  wrote:
> ... and I just realized that linux-audit isn't on the To/CC line,
> adding them now.
> 
> Link to the patch is below.
> 
> * https://marc.info/?t=15204188763=1=2

Yes...I wished I was in on the beginning of this discussion. Here's the
problem. We need all tasks auditable unless specifically dismissed as
uninteresting. This would be a task,never rule.

The way we look at it, is if it boots with audit=1, then we know auditd
is expected to run at some point. So, we need all tasks to stay
auditable. If they weren't and auditd enabled auditing, then we'd need
to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
process in the system. It was decided that this is too ugly.

So, we need them all to be auditable if there is any intent to audit.
It doesn't matter if there are rules loaded or not. All processes have
to stay within reach.

What might be acceptable is to add one more state to audit boot variable
to indicate that auditing is never expected. We currently have:
disabled - which means we'll decide later, enabled, and immutable (no
changes allowed). Then have calls to audit_enable or loading rules
fail on that flag state so that user space can log that there is a
conflict (boot vs daemon) that has to be resolved. As long as we can
fail in a discoverable way, I think it would be OK to do something like
this. Also, I don't think we want that to be the default state at the
moment because the current default is keep all processes auditable.

-Steve

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Steve Grubb]

On Wed, 7 Mar 2018 18:43:42 -0500
Paul Moore  wrote:
> ... and I just realized that linux-audit isn't on the To/CC line,
> adding them now.
> 
> Link to the patch is below.
> 
> * https://marc.info/?t=15204188763=1=2

Yes...I wished I was in on the beginning of this discussion. Here's the
problem. We need all tasks auditable unless specifically dismissed as
uninteresting. This would be a task,never rule.

The way we look at it, is if it boots with audit=1, then we know auditd
is expected to run at some point. So, we need all tasks to stay
auditable. If they weren't and auditd enabled auditing, then we'd need
to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every
process in the system. It was decided that this is too ugly.

So, we need them all to be auditable if there is any intent to audit.
It doesn't matter if there are rules loaded or not. All processes have
to stay within reach.

What might be acceptable is to add one more state to audit boot variable
to indicate that auditing is never expected. We currently have:
disabled - which means we'll decide later, enabled, and immutable (no
changes allowed). Then have calls to audit_enable or loading rules
fail on that flag state so that user space can log that there is a
conflict (boot vs daemon) that has to be resolved. As long as we can
fail in a discoverable way, I think it would be OK to do something like
this. Also, I don't think we want that to be the default state at the
moment because the current default is keep all processes auditable.

-Steve

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Steve Grubb]

On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> Tracefs or debugfs were causing hundreds to thousands of null PATH
> records to be associated with the init_module and finit_module SYSCALL
> records on a few modules when the following rule was in place for
> startup:
> -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> 
> This happens because the parent inode is not found in the task's
> audit_names list and hence treats it as anonymous.  This gives us no
> information other than a numerical device number for a device that may
> no longer be visible upon log inspeciton, and an inode number.
> 
> Fill in the partial known pathname from the filesystem mount point to
> the leaf node on previously null PATH records from entries that have an
> anonymous parent from the child dentry using dentry_path_raw().
> 
> Make the dentry argument of __audit_inode_child() non-const so that we
> can take a reference to it in the case of an anonymous parent with
> dget() and dget_parent() to be able to later print a partial path from
> the host filesystem rather than null.
> 
> Since all we are given is an inode of the parent and the dentry of the
> child, finding the path from the mount point to the root of the
> filesystem is more challenging that would involve searching all
> vfsmounts from "/" until a matching dentry is found for that
> filesystem's root dentry.  Even if one is found, there may be more than
> one mount point.  At this point the gain seems marginal since
> knowing the filesystem type and path are a significant help in tracking
> down the source of the PATH records and being able to address them.
> 
> Sample output:
> type=PROCTITLE msg=audit(1488317694.446:143):
> proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> msg=audit(1488317694.446:143): item=797
> name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> nametype=CREATE cap_fp= cap_fi= cap_fe=0
> cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> cap_fi= cap_fe=0 cap_fver=0 type=PATH
> msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> nametype=PARENT cap_fp= cap_fi= cap_fe=0
> cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> subj=system_u:system_r:insmod_t:s0 key="mod-load"

Thanks for the samples, but the event above fails the ausearch-test test 
suite. The "name" field in the PATH record is not properly escaped.

-Steve

> See: https://github.com/linux-audit/audit-kernel/issues/8
> Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> 
> Signed-off-by: Richard Guy Briggs 
> 
> ---
> v4:
>   fix fullpath memleak
>   switch from log_format() to audit_log_untrustedstring()
>   remove leading / from pathname relative to unknown mount point
> 
> v3:
>   fix audit_buffer leak and dname error allocation leak audit_log_name
>   only put audit_name->dentry if it is being replaced
> 
> v2:
>   deconstify struct dentry*
>   add hex prefix to fstype
> ---
>  include/linux/audit.h |  8 
>  kernel/audit.c| 28 +++-
>  kernel/audit.h|  1 +
>  kernel/auditsc.c  |  8 +++-
>  4 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..2020f1d 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -232,7 +232,7 @@ extern void __audit_inode(struct filename *name, const
> struct dentry *dentry, unsigned int flags);
>  extern void __audit_file(const struct file *);
>  extern void __audit_inode_child(struct inode *parent,
> - const struct dentry *dentry,
> + struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
>  extern void __audit_ptrace(struct task_struct *t);
> @@ -297,7 +297,7 @@ static inline void audit_inode_parent_hidden(struct
> filename *name, AUDIT_INODE_PARENT | 

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Steve Grubb]

On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> Tracefs or debugfs were causing hundreds to thousands of null PATH
> records to be associated with the init_module and finit_module SYSCALL
> records on a few modules when the following rule was in place for
> startup:
> -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> 
> This happens because the parent inode is not found in the task's
> audit_names list and hence treats it as anonymous.  This gives us no
> information other than a numerical device number for a device that may
> no longer be visible upon log inspeciton, and an inode number.
> 
> Fill in the partial known pathname from the filesystem mount point to
> the leaf node on previously null PATH records from entries that have an
> anonymous parent from the child dentry using dentry_path_raw().
> 
> Make the dentry argument of __audit_inode_child() non-const so that we
> can take a reference to it in the case of an anonymous parent with
> dget() and dget_parent() to be able to later print a partial path from
> the host filesystem rather than null.
> 
> Since all we are given is an inode of the parent and the dentry of the
> child, finding the path from the mount point to the root of the
> filesystem is more challenging that would involve searching all
> vfsmounts from "/" until a matching dentry is found for that
> filesystem's root dentry.  Even if one is found, there may be more than
> one mount point.  At this point the gain seems marginal since
> knowing the filesystem type and path are a significant help in tracking
> down the source of the PATH records and being able to address them.
> 
> Sample output:
> type=PROCTITLE msg=audit(1488317694.446:143):
> proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> msg=audit(1488317694.446:143): item=797
> name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> nametype=CREATE cap_fp= cap_fi= cap_fe=0
> cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> cap_fi= cap_fe=0 cap_fver=0 type=PATH
> msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> nametype=PARENT cap_fp= cap_fi= cap_fe=0
> cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> subj=system_u:system_r:insmod_t:s0 key="mod-load"

Thanks for the samples, but the event above fails the ausearch-test test 
suite. The "name" field in the PATH record is not properly escaped.

-Steve

> See: https://github.com/linux-audit/audit-kernel/issues/8
> Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> 
> Signed-off-by: Richard Guy Briggs 
> 
> ---
> v4:
>   fix fullpath memleak
>   switch from log_format() to audit_log_untrustedstring()
>   remove leading / from pathname relative to unknown mount point
> 
> v3:
>   fix audit_buffer leak and dname error allocation leak audit_log_name
>   only put audit_name->dentry if it is being replaced
> 
> v2:
>   deconstify struct dentry*
>   add hex prefix to fstype
> ---
>  include/linux/audit.h |  8 
>  kernel/audit.c| 28 +++-
>  kernel/audit.h|  1 +
>  kernel/auditsc.c  |  8 +++-
>  4 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..2020f1d 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -232,7 +232,7 @@ extern void __audit_inode(struct filename *name, const
> struct dentry *dentry, unsigned int flags);
>  extern void __audit_file(const struct file *);
>  extern void __audit_inode_child(struct inode *parent,
> - const struct dentry *dentry,
> + struct dentry *dentry,
>   const unsigned char type);
>  extern void __audit_seccomp(unsigned long syscall, long signr, int code);
>  extern void __audit_ptrace(struct task_struct *t);
> @@ -297,7 +297,7 @@ static inline void audit_inode_parent_hidden(struct
> filename *name, AUDIT_INODE_PARENT | AUDIT_INODE_HIDDEN);
> 

Re: [RFC PATCH ghak21 0/4] audit: address ANOM_LINK excess records

[Steve Grubb]

On Wednesday, February 14, 2018 11:18:20 AM EST Richard Guy Briggs wrote:
> Audit link denied events were being unexpectedly produced in a disjoint
> way when audit was disabled, and when they were expected, there were
> duplicate PATH records.  This patchset addresses both issues for
> symlinks and hardlinks.
> 
> This was introduced with
>   commit b24a30a7305418ff138ff51776fc555ec57c011a
>   ("audit: fix event coverage of AUDIT_ANOM_LINK")
>   commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc
>   ("fs: add link restriction audit reporting")
> 
> Here are the resulting events:

Have these been tested with ausearch-test?

> symlink:
> type=PROCTITLE msg=audit(02/14/2018 04:40:21.635:238) : proctitle=cat
> my-passwd type=PATH msg=audit(02/14/2018 04:40:21.635:238) : item=1
> name=/tmp/my-passwd inode=17618 dev=00:27 mode=link,777 ouid=rgb ogid=rgb
> rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL
> cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018
> 04:40:21.635:238) : item=0 name=/tmp inode=13446 dev=00:27
> mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none
> cap_fe=0 cap_fver=0 type=CWD msg=audit(02/14/2018 04:40:21.635:238) :
> cwd=/tmp
> type=SYSCALL msg=audit(02/14/2018 04:40:21.635:238) : arch=x86_64
> syscall=openat success=no exit=EACCES(Permission denied) a0=0xff9c
> a1=0x7ffc6c1acdda a2=O_RDONLY a3=0x0 items=2 ppid=549 pid=606 auid=root
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=ttyS0 ses=1 comm= cat exe=/usr/bin/cat
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(02/14/2018 04:40:21.635:238) : op=follow_link
> ppid=549 pid=606 auid=root uid=root gid=root euid=root suid=root
> fsuid=root egid=roo t sgid=root fsgid=root tty=ttyS0 ses=1 comm=cat
> exe=/usr/bin/cat
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no

This record duplicates the SYSCALL event except for the op field. I would 
suggest that is the only field needed.

> 
> hardlink:
> type=PROCTITLE msg=audit(02/14/2018 04:40:25.373:239) : proctitle=ln test
> test-ln type=PATH msg=audit(02/14/2018 04:40:25.373:239) : item=1
> name=/tmp inode=13446 dev=00:27 mode=dir,sticky,777 ouid=root ogid=root
> rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018
> 04:40:25.373:239) : item=0 name=test inode=17619 dev=00:27 mode=file,700
> ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD
> msg=audit(02/14/2018 04:40:25.373:239) : cwd=/tmp
> type=SYSCALL msg=audit(02/14/2018 04:40:25.373:239) : arch=x86_64
> syscall=linkat success=no exit=EPERM(Operation not permitted)
> a0=0xff9c a1=0x7fffe6c3f628 a2=0xff9c a3=0x7fffe6c3f62d items=2
> ppid=578 pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb
> egid=rgb sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(02/14/2018 04:40:25.373:239) : op=linkat ppid=578
> pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb
> sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
> 
> The remaining problem is how to address this when syscall logging is
> disabled since it needs a parent path record and/or a CWD record to
> complete it.  It could also use a proctitle record too.  In fact, it
> looks like we need a way to have multiple auxiliary records to support
> an arbitrary record.  Comments please.

Perhaps this can only be emitted correctly with SYSCALL auditing enabled. 
Otherwise, the event should stand completely on its own without syscall and 
path records. The information from them can be added, but it risks hitting 
the record size limit.

-Steve

> See: https://github.com/linux-audit/audit-kernel/issues/21
> See also: https://github.com/linux-audit/audit-kernel/issues/51
> 
> Richard Guy Briggs (4):
>   audit: make ANOM_LINK obey audit_enabled and audit_dummy_context
>   audit: link denied should not directly generate PATH record
>   audit: add refused symlink to audit_names
>   audit: add parent of refused symlink to audit_names
> 
>  fs/namei.c | 10 ++
>  kernel/audit.c | 13 ++---
>  2 files changed, 12 insertions(+), 11 deletions(-)

Re: [RFC PATCH ghak21 0/4] audit: address ANOM_LINK excess records

[Steve Grubb]

On Wednesday, February 14, 2018 11:18:20 AM EST Richard Guy Briggs wrote:
> Audit link denied events were being unexpectedly produced in a disjoint
> way when audit was disabled, and when they were expected, there were
> duplicate PATH records.  This patchset addresses both issues for
> symlinks and hardlinks.
> 
> This was introduced with
>   commit b24a30a7305418ff138ff51776fc555ec57c011a
>   ("audit: fix event coverage of AUDIT_ANOM_LINK")
>   commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc
>   ("fs: add link restriction audit reporting")
> 
> Here are the resulting events:

Have these been tested with ausearch-test?

> symlink:
> type=PROCTITLE msg=audit(02/14/2018 04:40:21.635:238) : proctitle=cat
> my-passwd type=PATH msg=audit(02/14/2018 04:40:21.635:238) : item=1
> name=/tmp/my-passwd inode=17618 dev=00:27 mode=link,777 ouid=rgb ogid=rgb
> rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL
> cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018
> 04:40:21.635:238) : item=0 name=/tmp inode=13446 dev=00:27
> mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none
> cap_fe=0 cap_fver=0 type=CWD msg=audit(02/14/2018 04:40:21.635:238) :
> cwd=/tmp
> type=SYSCALL msg=audit(02/14/2018 04:40:21.635:238) : arch=x86_64
> syscall=openat success=no exit=EACCES(Permission denied) a0=0xff9c
> a1=0x7ffc6c1acdda a2=O_RDONLY a3=0x0 items=2 ppid=549 pid=606 auid=root
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=ttyS0 ses=1 comm= cat exe=/usr/bin/cat
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(02/14/2018 04:40:21.635:238) : op=follow_link
> ppid=549 pid=606 auid=root uid=root gid=root euid=root suid=root
> fsuid=root egid=roo t sgid=root fsgid=root tty=ttyS0 ses=1 comm=cat
> exe=/usr/bin/cat
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no

This record duplicates the SYSCALL event except for the op field. I would 
suggest that is the only field needed.

> 
> hardlink:
> type=PROCTITLE msg=audit(02/14/2018 04:40:25.373:239) : proctitle=ln test
> test-ln type=PATH msg=audit(02/14/2018 04:40:25.373:239) : item=1
> name=/tmp inode=13446 dev=00:27 mode=dir,sticky,777 ouid=root ogid=root
> rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018
> 04:40:25.373:239) : item=0 name=test inode=17619 dev=00:27 mode=file,700
> ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD
> msg=audit(02/14/2018 04:40:25.373:239) : cwd=/tmp
> type=SYSCALL msg=audit(02/14/2018 04:40:25.373:239) : arch=x86_64
> syscall=linkat success=no exit=EPERM(Operation not permitted)
> a0=0xff9c a1=0x7fffe6c3f628 a2=0xff9c a3=0x7fffe6c3f62d items=2
> ppid=578 pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb
> egid=rgb sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=ANOM_LINK msg=audit(02/14/2018 04:40:25.373:239) : op=linkat ppid=578
> pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb
> sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
> 
> The remaining problem is how to address this when syscall logging is
> disabled since it needs a parent path record and/or a CWD record to
> complete it.  It could also use a proctitle record too.  In fact, it
> looks like we need a way to have multiple auxiliary records to support
> an arbitrary record.  Comments please.

Perhaps this can only be emitted correctly with SYSCALL auditing enabled. 
Otherwise, the event should stand completely on its own without syscall and 
path records. The information from them can be added, but it risks hitting 
the record size limit.

-Steve

> See: https://github.com/linux-audit/audit-kernel/issues/21
> See also: https://github.com/linux-audit/audit-kernel/issues/51
> 
> Richard Guy Briggs (4):
>   audit: make ANOM_LINK obey audit_enabled and audit_dummy_context
>   audit: link denied should not directly generate PATH record
>   audit: add refused symlink to audit_names
>   audit: add parent of refused symlink to audit_names
> 
>  fs/namei.c | 10 ++
>  kernel/audit.c | 13 ++---
>  2 files changed, 12 insertions(+), 11 deletions(-)

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Monday, December 11, 2017 11:30:57 AM EST Eric Paris wrote:
> > Because a container doesn't have to use namespaces to be a container
> > you still need a mechanism for a process to declare that it is in
> > fact
> > in a container, and to identify the container.
> 
> I like the idea but I'm still tossing it around in my head (and
> thinking about Casey's statement too). Lets say we have a 'docker-like'
> container with pid=100  netns=X,userns=Y,mountns=Z. If I'm on the host
> in all init namespaces and I run
>   nsenter -t 100 -n ip link set eth0 promisc on
> How should this be logged?

If it is a normal process, then everything would match the init name space and 
you wouldn't have entered a container. If it were a container, any generated 
event should have the container ID from registration attached to it.

> Did this command run in it's own 'container' unrelated to the 'docker-like'
> container?

That should be determined by what's in the task struct.

-Steve

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Monday, December 11, 2017 11:30:57 AM EST Eric Paris wrote:
> > Because a container doesn't have to use namespaces to be a container
> > you still need a mechanism for a process to declare that it is in
> > fact
> > in a container, and to identify the container.
> 
> I like the idea but I'm still tossing it around in my head (and
> thinking about Casey's statement too). Lets say we have a 'docker-like'
> container with pid=100  netns=X,userns=Y,mountns=Z. If I'm on the host
> in all init namespaces and I run
>   nsenter -t 100 -n ip link set eth0 promisc on
> How should this be logged?

If it is a normal process, then everything would match the init name space and 
you wouldn't have entered a container. If it were a container, any generated 
event should have the container ID from registration attached to it.

> Did this command run in it's own 'container' unrelated to the 'docker-like'
> container?

That should be determined by what's in the task struct.

-Steve

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Thursday, November 9, 2017 3:52:46 PM EST Richard Guy Briggs wrote:
> > >> > It might be simplest to just apply a corrective patch over top of
> > >> > this one so that you don't have to muck about with git branches and
> > >> > commit messages.
> > >> 
> > >> A quick note on the "corrective patch": given we are just days away
> > >> from the merge window opening, it is *way* to late for something like
> > >> that, at this point the only options are to leave it as-is or
> > >> yank/revert and make another pass during the next development phase.
> > > 
> > > Then yank it. I think that is overreacting but given the options you
> > > presented its the only one that avoids changing a critical field
> > > format.
> > 
> > It's not overreacting Steve, there is simply no way we can test and
> > adequately soak new changes in the few days we have left.

Its just moving the output of the information a few lines down further in the 
code. 10 minutes of work, tops.

> > Event yanks/reverts carry a risk at this stage, but I consider that the
> > less risky option for these patches.  Neither is a great option, and that
> > is why I'm rather annoyed.
>
> I don't really see that this is my choice to include it or not.  This is
> the upstream maintainer's decision.
> 
> I can't say I'd be thrilled to have my name on something that stuffs up
> the system though.  It still isn't clear to me why an incomplete path
> from some seemingly random place in the filesystem tree is preferable to
> something that gives it an anchor point, at least to human interpreters.

The path should stay. Just the file system type needs decoupling and moving.

> Adding an fstype to the record is an interesting idea, but then creates
> a void for all the rest of the properly formed records that don't need
> it and will need more work to find it, wasting bandwidth with
> "fstype=?". 

I would let it optionally swing in and out at the end of the record. This 
should never show up on a normal system because the rules will suppress 
generating this information by default. So, it really won't be all that 
visible.

> How are the analysis tools stymied by a text prefix to a path that it can't
> find anyways?

Because they do not actually resolve anything in the file system. They take 
the event as ground truth and use that. Also, the tools expect name=value. 
This has been the way since the beginning. We do not lump multiple independent 
values together. And then what if the path has a special character in it? The 
whole value then has to be encoded. And I don't think the patch is using 
untrusted string like it should.

> Since we have a chance to fix it before it goes upstream, I think it
> should either be yanked and respun, or add a corrective patch and submit
> them together.
> 
> > >> As for the objection itself: ungh.  There is really no good reason why
> > >> you couldn't have seen this in the *several* *months* prior to this;
> > >> Richard wrote a nice patch description which *included* sample audit
> > >> events, and you were involved in discussions regarding this patchset.
> > >> To say I'm disappointed would be an understatement.
> > > 
> > > I am also disappointed to find that we are modifying a searchable field
> > > that has been defined since 2005. The "name" field is very important.
> > > It's used in quite a few reports, its used in the text format, it's
> > > searchable, and we have a dictionary that defines exactly what it is.
> > > Fields that are searchable and used in common reports cannot be changed
> > > without a whole lot of coordination. I'm also disappointed to have to
> > > point out that new information should go in its own field. I thought
> > > this was common knowledge. In any event, it was caught and problems can
> > > be avoided.
> 
> So why does this make it unsearchable?

I didn't say it makes in unsearchable, but now that you mention it...it does 
in one case. Searchable fields are more important. They typically are the 
object or subject or some kind of special attribute that is commonly searched 
on to group events. Searchable fields can either be partial or full word 
match. By combining information in the same field, it will change this 
behavior. The path name is the object of the event. By combining information 
that is not the object with it, everyone will have to change and update their 
software to handle this change in behavior.

> I still don't understand any explanations that have been made so far

Try ausearch --text on those events, or aureport --file.

-Steve

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Thursday, November 9, 2017 3:52:46 PM EST Richard Guy Briggs wrote:
> > >> > It might be simplest to just apply a corrective patch over top of
> > >> > this one so that you don't have to muck about with git branches and
> > >> > commit messages.
> > >> 
> > >> A quick note on the "corrective patch": given we are just days away
> > >> from the merge window opening, it is *way* to late for something like
> > >> that, at this point the only options are to leave it as-is or
> > >> yank/revert and make another pass during the next development phase.
> > > 
> > > Then yank it. I think that is overreacting but given the options you
> > > presented its the only one that avoids changing a critical field
> > > format.
> > 
> > It's not overreacting Steve, there is simply no way we can test and
> > adequately soak new changes in the few days we have left.

Its just moving the output of the information a few lines down further in the 
code. 10 minutes of work, tops.

> > Event yanks/reverts carry a risk at this stage, but I consider that the
> > less risky option for these patches.  Neither is a great option, and that
> > is why I'm rather annoyed.
>
> I don't really see that this is my choice to include it or not.  This is
> the upstream maintainer's decision.
> 
> I can't say I'd be thrilled to have my name on something that stuffs up
> the system though.  It still isn't clear to me why an incomplete path
> from some seemingly random place in the filesystem tree is preferable to
> something that gives it an anchor point, at least to human interpreters.

The path should stay. Just the file system type needs decoupling and moving.

> Adding an fstype to the record is an interesting idea, but then creates
> a void for all the rest of the properly formed records that don't need
> it and will need more work to find it, wasting bandwidth with
> "fstype=?". 

I would let it optionally swing in and out at the end of the record. This 
should never show up on a normal system because the rules will suppress 
generating this information by default. So, it really won't be all that 
visible.

> How are the analysis tools stymied by a text prefix to a path that it can't
> find anyways?

Because they do not actually resolve anything in the file system. They take 
the event as ground truth and use that. Also, the tools expect name=value. 
This has been the way since the beginning. We do not lump multiple independent 
values together. And then what if the path has a special character in it? The 
whole value then has to be encoded. And I don't think the patch is using 
untrusted string like it should.

> Since we have a chance to fix it before it goes upstream, I think it
> should either be yanked and respun, or add a corrective patch and submit
> them together.
> 
> > >> As for the objection itself: ungh.  There is really no good reason why
> > >> you couldn't have seen this in the *several* *months* prior to this;
> > >> Richard wrote a nice patch description which *included* sample audit
> > >> events, and you were involved in discussions regarding this patchset.
> > >> To say I'm disappointed would be an understatement.
> > > 
> > > I am also disappointed to find that we are modifying a searchable field
> > > that has been defined since 2005. The "name" field is very important.
> > > It's used in quite a few reports, its used in the text format, it's
> > > searchable, and we have a dictionary that defines exactly what it is.
> > > Fields that are searchable and used in common reports cannot be changed
> > > without a whole lot of coordination. I'm also disappointed to have to
> > > point out that new information should go in its own field. I thought
> > > this was common knowledge. In any event, it was caught and problems can
> > > be avoided.
> 
> So why does this make it unsearchable?

I didn't say it makes in unsearchable, but now that you mention it...it does 
in one case. Searchable fields are more important. They typically are the 
object or subject or some kind of special attribute that is commonly searched 
on to group events. Searchable fields can either be partial or full word 
match. By combining information in the same field, it will change this 
behavior. The path name is the object of the event. By combining information 
that is not the object with it, everyone will have to change and update their 
software to handle this change in behavior.

> I still don't understand any explanations that have been made so far

Try ausearch --text on those events, or aureport --file.

-Steve

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Thursday, November 9, 2017 10:18:10 AM EST Paul Moore wrote:
> On Wed, Nov 8, 2017 at 6:29 PM, Steve Grubb <sgr...@redhat.com> wrote:
> > On Wednesday, September 20, 2017 12:52:32 PM EST Paul Moore wrote:
> >> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs <r...@redhat.com> 
wrote:
> >> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> >> > records to be associated with the init_module and finit_module SYSCALL
> >> > records on a few modules when the following rule was in place for
> >> > 
> >> > startup:
> >> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> >> > 
> >> > This happens because the parent inode is not found in the task's
> >> > audit_names list and hence treats it as anonymous.  This gives us no
> >> > information other than a numerical device number that may no longer be
> >> > visible upon log inspeciton, and an inode number.
> >> > 
> >> > Fill in the filesystem type, filesystem magic number and full pathname
> >> > from the filesystem mount point on previously null PATH records from
> >> > entries that have an anonymous parent from the child dentry using
> >> > dentry_path_raw().
> > 
> > Late reply...but I just noticed that this changes the format of the "name"
> > field - which is undesirable. Please put the file system type in a field
> > all by itself called "fstype". You can just leave it as the hex magic
> > number prepended with 0x and user space can do the lookup from there,
> > 
> > It might be simplest to just apply a corrective patch over top of this one
> > so that you don't have to muck about with git branches and commit
> > messages.
>
> A quick note on the "corrective patch": given we are just days away
> from the merge window opening, it is *way* to late for something like
> that, at this point the only options are to leave it as-is or
> yank/revert and make another pass during the next development phase.

Then yank it. I think that is overreacting but given the options you presented 
its the only one that avoids changing a critical field format.
 
> As for the objection itself: ungh.  There is really no good reason why
> you couldn't have seen this in the *several* *months* prior to this;
> Richard wrote a nice patch description which *included* sample audit
> events, and you were involved in discussions regarding this patchset.
> To say I'm disappointed would be an understatement.

I am also disappointed to find that we are modifying a searchable field that 
has been defined since 2005. The "name" field is very important. It's used in 
quite a few reports, its used in the text format, it's searchable, and we have 
a dictionary that defines exactly what it is. Fields that are searchable and 
used in common reports cannot be changed without a whole lot of coordination. 
I'm also disappointed to have to point out that new information should go in 
its own field. I thought this was common knowledge. In any event, it was 
caught and problems can be avoided.

-Steve

> I need to look at the rest of audit/next to see what a mess things
> would be if I yanked this patch.  I don't expect it to be bad, but
> taking a look will also give Richard a chance to voice his thoughts;
> it is his patch after all, it would be nice to see an "OK" from him.
> Whatever we do, it needs to happen by the of the day today (Thursday,
> November 9th) as we need time to build and test the revised patches.

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Thursday, November 9, 2017 10:18:10 AM EST Paul Moore wrote:
> On Wed, Nov 8, 2017 at 6:29 PM, Steve Grubb  wrote:
> > On Wednesday, September 20, 2017 12:52:32 PM EST Paul Moore wrote:
> >> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs  
wrote:
> >> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> >> > records to be associated with the init_module and finit_module SYSCALL
> >> > records on a few modules when the following rule was in place for
> >> > 
> >> > startup:
> >> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> >> > 
> >> > This happens because the parent inode is not found in the task's
> >> > audit_names list and hence treats it as anonymous.  This gives us no
> >> > information other than a numerical device number that may no longer be
> >> > visible upon log inspeciton, and an inode number.
> >> > 
> >> > Fill in the filesystem type, filesystem magic number and full pathname
> >> > from the filesystem mount point on previously null PATH records from
> >> > entries that have an anonymous parent from the child dentry using
> >> > dentry_path_raw().
> > 
> > Late reply...but I just noticed that this changes the format of the "name"
> > field - which is undesirable. Please put the file system type in a field
> > all by itself called "fstype". You can just leave it as the hex magic
> > number prepended with 0x and user space can do the lookup from there,
> > 
> > It might be simplest to just apply a corrective patch over top of this one
> > so that you don't have to muck about with git branches and commit
> > messages.
>
> A quick note on the "corrective patch": given we are just days away
> from the merge window opening, it is *way* to late for something like
> that, at this point the only options are to leave it as-is or
> yank/revert and make another pass during the next development phase.

Then yank it. I think that is overreacting but given the options you presented 
its the only one that avoids changing a critical field format.
 
> As for the objection itself: ungh.  There is really no good reason why
> you couldn't have seen this in the *several* *months* prior to this;
> Richard wrote a nice patch description which *included* sample audit
> events, and you were involved in discussions regarding this patchset.
> To say I'm disappointed would be an understatement.

I am also disappointed to find that we are modifying a searchable field that 
has been defined since 2005. The "name" field is very important. It's used in 
quite a few reports, its used in the text format, it's searchable, and we have 
a dictionary that defines exactly what it is. Fields that are searchable and 
used in common reports cannot be changed without a whole lot of coordination. 
I'm also disappointed to have to point out that new information should go in 
its own field. I thought this was common knowledge. In any event, it was 
caught and problems can be avoided.

-Steve

> I need to look at the rest of audit/next to see what a mess things
> would be if I yanked this patch.  I don't expect it to be bad, but
> taking a look will also give Richard a chance to voice his thoughts;
> it is his patch after all, it would be nice to see an "OK" from him.
> Whatever we do, it needs to happen by the of the day today (Thursday,
> November 9th) as we need time to build and test the revised patches.

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Wednesday, September 20, 2017 12:52:32 PM EST Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs  wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > 
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > 
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number that may no longer be
> > visible upon log inspeciton, and an inode number.
> > 
> > Fill in the filesystem type, filesystem magic number and full pathname
> > from the filesystem mount point on previously null PATH records from
> > entries that have an anonymous parent from the child dentry using
> > dentry_path_raw().

Late reply...but I just noticed that this changes the format of the "name" 
field - which is undesirable. Please put the file system type in a field all 
by itself called "fstype". You can just leave it as the hex magic number 
prepended with 0x and user space can do the lookup from there,

It might be simplest to just apply a corrective patch over top of this one so 
that you don't have to muck about with git branches and commit messages.

-Steve
 
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> > 
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being to address them.
> > 
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143):
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > msg=audit(1488317694.446:143): item=797
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid/format inode=15969
> > dev=00:09 mode=0100444 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE type=PATH
> > msg=audit(1488317694.446:143): item=796
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid inode=15964
> > dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=PARENT ...
> > type=PATH msg=audit(1488317694.446:143): item=1
> > name=tracefs(74726163):/events/nfs4 inode=15571 dev=00:09 mode=040755
> > ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=CREATE type=PATH msg=audit(1488317694.446:143): item=0
> > name=tracefs(74726163):/events inode=119 dev=00:09 mode=040755 ouid=0
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > type=UNKNOWN[1330] msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6
> > pid=528 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> > 
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> > 
> > Signed-off-by: Richard Guy Briggs 
> > 
> > ---
> > 
> > v3:
> >   fix audit_buffer leak and dname error allocation leak audit_log_name
> >   only put audit_name->dentry if it is being replaced
> > 
> > v2:
> >   minor cosmetic changes and support fs filter patch
> > 
> > ---
> > 
> >  include/linux/audit.h |8 
> >  kernel/audit.c|   19 +++
> >  kernel/audit.h|1 +
> >  kernel/auditsc.c  |8 +++-
> >  4 files changed, 31 insertions(+), 5 deletions(-)
> 
> ...
> 
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 59e60e0..d6e6e4e 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -72,6 +72,7 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > 
> >  #include "audit.h"
> > 
> > @@ -2047,6 +2048,10 @@ void audit_copy_inode(struct audit_names *name,
> > const struct dentry *dentry,> 
> > name->gid   = inode->i_gid;
> > name->rdev  = inode->i_rdev;
> > security_inode_getsecid(inode, >osid);
> > 
> > +   if (name->dentry) {
> > +   dput(name->dentry);
> > +   name->dentry = 

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

[Steve Grubb]

On Wednesday, September 20, 2017 12:52:32 PM EST Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs  wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > 
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > 
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number that may no longer be
> > visible upon log inspeciton, and an inode number.
> > 
> > Fill in the filesystem type, filesystem magic number and full pathname
> > from the filesystem mount point on previously null PATH records from
> > entries that have an anonymous parent from the child dentry using
> > dentry_path_raw().

Late reply...but I just noticed that this changes the format of the "name" 
field - which is undesirable. Please put the file system type in a field all 
by itself called "fstype". You can just leave it as the hex magic number 
prepended with 0x and user space can do the lookup from there,

It might be simplest to just apply a corrective patch over top of this one so 
that you don't have to muck about with git branches and commit messages.

-Steve
 
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> > 
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being to address them.
> > 
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143):
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > msg=audit(1488317694.446:143): item=797
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid/format inode=15969
> > dev=00:09 mode=0100444 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE type=PATH
> > msg=audit(1488317694.446:143): item=796
> > name=tracefs(74726163):/events/nfs4/nfs4_setclientid inode=15964
> > dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=PARENT ...
> > type=PATH msg=audit(1488317694.446:143): item=1
> > name=tracefs(74726163):/events/nfs4 inode=15571 dev=00:09 mode=040755
> > ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=CREATE type=PATH msg=audit(1488317694.446:143): item=0
> > name=tracefs(74726163):/events inode=119 dev=00:09 mode=040755 ouid=0
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > type=UNKNOWN[1330] msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6
> > pid=528 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> > 
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> > 
> > Signed-off-by: Richard Guy Briggs 
> > 
> > ---
> > 
> > v3:
> >   fix audit_buffer leak and dname error allocation leak audit_log_name
> >   only put audit_name->dentry if it is being replaced
> > 
> > v2:
> >   minor cosmetic changes and support fs filter patch
> > 
> > ---
> > 
> >  include/linux/audit.h |8 
> >  kernel/audit.c|   19 +++
> >  kernel/audit.h|1 +
> >  kernel/auditsc.c  |8 +++-
> >  4 files changed, 31 insertions(+), 5 deletions(-)
> 
> ...
> 
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 59e60e0..d6e6e4e 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -72,6 +72,7 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > 
> >  #include "audit.h"
> > 
> > @@ -2047,6 +2048,10 @@ void audit_copy_inode(struct audit_names *name,
> > const struct dentry *dentry,> 
> > name->gid   = inode->i_gid;
> > name->rdev  = inode->i_rdev;
> > security_inode_getsecid(inode, >osid);
> > 
> > +   if (name->dentry) {
> > +   dput(name->dentry);
> > +   name->dentry = NULL;
> > +   }
> > 
> > 

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Thursday, October 19, 2017 7:11:33 PM EDT Aleksa Sarai wrote:
> >>> The registration is a pseudo filesystem (proc, since PID tree already
> >>> exists) write of a u8[16] UUID representing the container ID to a file
> >>> representing a process that will become the first process in a new
> >>> container.  This write might place restrictions on mount namespaces
> >>> required to define a container, or at least careful checking of
> >>> namespaces in the kernel to verify permissions of the orchestrator so it
> >>> can't change its own container ID.  A bind mount of nsfs may be
> >>> necessary in the container orchestrator's mntNS.
> >>> Note: Use a 128-bit scalar rather than a string to make compares faster
> >>> and simpler.
> >>> 
> >>> Require a new CAP_CONTAINER_ADMIN to be able to carry out the
> >>> registration.
> >> 
> >> Wouldn't CAP_AUDIT_WRITE be sufficient? After all, this is for auditing.
> > 
> > No, because then any process with that capability (vsftpd) could change
> > its own container ID.  This is discussed more in other parts of the
> > thread...

For the record, I changed my mind. CAP_AUDIT_CONTROL is the correct 
capability. 

> Not if we make the container ID append-only (to support nesting), or
> write-once (the other idea thrown around). 

Well...I like to use lessons learned if they can be applied. In the normal 
world without containers we have uid, auid, and session_id. uid is who you are 
now, auid is how you got into the system, session_id distinguishes individual 
auids. We have a default auid of -1 for system objects and a real number for 
people.

I think there should be the equivalent of auid and session_id but tailored for 
containers. Loginuid == container id. It can be set, overridden, or appended 
to (we'll figure this out later) in very limited circumstances. 
Container_session == session which is tamper-proof. This way things can enter 
a container with the same ID but under a different session. And everything 
else gets to inherit the original ID. This way we can trace actions to 
something that entered the container rather than normal system activity in the 
container.

What a security officer wants to know is what did people do inside the 
system / container. The system objects we typically don't care about. Sure 
they might get hacked and then work on behalf of someone, but they would 
almost always pop a shell so that they can have freedom. That should set off 
an AVC or create other activity that gets picked up.

-Steve

> In that case, you can't move "out" from a particular container ID, you can
> only go "deeper". These semantics don't make sense for generic containers,
> but since the point of this facility is *specifically* for audit I imagine
> that not being able to move a process from a sub-container's ID is a
> benefit.

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Thursday, October 19, 2017 7:11:33 PM EDT Aleksa Sarai wrote:
> >>> The registration is a pseudo filesystem (proc, since PID tree already
> >>> exists) write of a u8[16] UUID representing the container ID to a file
> >>> representing a process that will become the first process in a new
> >>> container.  This write might place restrictions on mount namespaces
> >>> required to define a container, or at least careful checking of
> >>> namespaces in the kernel to verify permissions of the orchestrator so it
> >>> can't change its own container ID.  A bind mount of nsfs may be
> >>> necessary in the container orchestrator's mntNS.
> >>> Note: Use a 128-bit scalar rather than a string to make compares faster
> >>> and simpler.
> >>> 
> >>> Require a new CAP_CONTAINER_ADMIN to be able to carry out the
> >>> registration.
> >> 
> >> Wouldn't CAP_AUDIT_WRITE be sufficient? After all, this is for auditing.
> > 
> > No, because then any process with that capability (vsftpd) could change
> > its own container ID.  This is discussed more in other parts of the
> > thread...

For the record, I changed my mind. CAP_AUDIT_CONTROL is the correct 
capability. 

> Not if we make the container ID append-only (to support nesting), or
> write-once (the other idea thrown around). 

Well...I like to use lessons learned if they can be applied. In the normal 
world without containers we have uid, auid, and session_id. uid is who you are 
now, auid is how you got into the system, session_id distinguishes individual 
auids. We have a default auid of -1 for system objects and a real number for 
people.

I think there should be the equivalent of auid and session_id but tailored for 
containers. Loginuid == container id. It can be set, overridden, or appended 
to (we'll figure this out later) in very limited circumstances. 
Container_session == session which is tamper-proof. This way things can enter 
a container with the same ID but under a different session. And everything 
else gets to inherit the original ID. This way we can trace actions to 
something that entered the container rather than normal system activity in the 
container.

What a security officer wants to know is what did people do inside the 
system / container. The system objects we typically don't care about. Sure 
they might get hacked and then work on behalf of someone, but they would 
almost always pop a shell so that they can have freedom. That should set off 
an AVC or create other activity that gets picked up.

-Steve

> In that case, you can't move "out" from a particular container ID, you can
> only go "deeper". These semantics don't make sense for generic containers,
> but since the point of this facility is *specifically* for audit I imagine
> that not being able to move a process from a sub-container's ID is a
> benefit.

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Tuesday, October 17, 2017 1:57:43 PM EDT James Bottomley wrote:
> > > > The idea is that processes spawned into a container would be
> > > > labelled by the container orchestration system.  It's unclear
> > > > what should happen to processes using nsenter after the fact, but
> > > > policy for that should be up to the orchestration system.
> > > 
> > > I'm fine with that. The user space policy can be anything y'all
> > > like.
> > 
> > I think there should be a login event.
> 
> I thought you wanted this for containers?  Container creation doesn't
> have login events.  In an unprivileged orchestration system it may be
> hard to synthetically manufacture them.

I realize this. This work is very similar to problems we've solved 12 years 
ago. We'll figure out what the right name is for it down the road. But the 
concept is the same. If something enters a container, we need to know about 
it. It needs to get tagged and be associated with the container. The way this 
was solved for the loginuid problem was to add a session identifier so that 
new logins of the same loginuid can coexist and we can trace actions back to a 
specific login. I'd think we can apply lessons learned from a while back to 
make container identification act similarly.

-Steve

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Tuesday, October 17, 2017 1:57:43 PM EDT James Bottomley wrote:
> > > > The idea is that processes spawned into a container would be
> > > > labelled by the container orchestration system.  It's unclear
> > > > what should happen to processes using nsenter after the fact, but
> > > > policy for that should be up to the orchestration system.
> > > 
> > > I'm fine with that. The user space policy can be anything y'all
> > > like.
> > 
> > I think there should be a login event.
> 
> I thought you wanted this for containers?  Container creation doesn't
> have login events.  In an unprivileged orchestration system it may be
> hard to synthetically manufacture them.

I realize this. This work is very similar to problems we've solved 12 years 
ago. We'll figure out what the right name is for it down the road. But the 
concept is the same. If something enters a container, we need to know about 
it. It needs to get tagged and be associated with the container. The way this 
was solved for the loginuid problem was to add a session identifier so that 
new logins of the same loginuid can coexist and we can trace actions back to a 
specific login. I'd think we can apply lessons learned from a while back to 
make container identification act similarly.

-Steve

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Tuesday, October 17, 2017 12:43:18 PM EDT Casey Schaufler wrote:
> > The idea is that processes spawned into a container would be labelled
> > by the container orchestration system.  It's unclear what should happen
> > to processes using nsenter after the fact, but policy for that should
> > be up to the orchestration system.
> 
> I'm fine with that. The user space policy can be anything y'all like.

I think there should be a login event.


> > The label will be used as a tag for audit information.
> 
> Deep breath ...
> 
> Which *is* a kernel security policy mechanism. Since the "label"
> is part of the audit information that the kernel is guaranteeing
> changing it would be covered by CAP_AUDIT_CONTROL. If the kernel
> does not use the "label" for any other purpose this is the only
> capability that makes sense for it.

I agree. The ability to set the container label grants the ability to evade 
rules or modify audit rules. CAP_AUDIT_CONTROL makes sense to me.


> > I think you were missing label inheritance above.
> > 
> > The security implications are that anything that can change the label
> > could also hide itself and its doings from the audit system and thus
> > would be used as a means to evade detection.

Yes. We have the same problem with loginuid. There are restrictions on who can 
change it once set. And then we made an immutable flag so that people that 
want a hard guarantee can get that.

-Steve

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Tuesday, October 17, 2017 12:43:18 PM EDT Casey Schaufler wrote:
> > The idea is that processes spawned into a container would be labelled
> > by the container orchestration system.  It's unclear what should happen
> > to processes using nsenter after the fact, but policy for that should
> > be up to the orchestration system.
> 
> I'm fine with that. The user space policy can be anything y'all like.

I think there should be a login event.


> > The label will be used as a tag for audit information.
> 
> Deep breath ...
> 
> Which *is* a kernel security policy mechanism. Since the "label"
> is part of the audit information that the kernel is guaranteeing
> changing it would be covered by CAP_AUDIT_CONTROL. If the kernel
> does not use the "label" for any other purpose this is the only
> capability that makes sense for it.

I agree. The ability to set the container label grants the ability to evade 
rules or modify audit rules. CAP_AUDIT_CONTROL makes sense to me.


> > I think you were missing label inheritance above.
> > 
> > The security implications are that anything that can change the label
> > could also hide itself and its doings from the audit system and thus
> > would be used as a means to evade detection.

Yes. We have the same problem with loginuid. There are restrictions on who can 
change it once set. And then we made an immutable flag so that people that 
want a hard guarantee can get that.

-Steve

Re: RFC(v2): Audit Kernel Container IDs

[Steve Grubb]

On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote:
> On 2017-10-12 16:33, Casey Schaufler wrote:
> > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote:
> > > Containers are a userspace concept.  The kernel knows nothing of them.
> > > 
> > > The Linux audit system needs a way to be able to track the container
> > > provenance of events and actions.  Audit needs the kernel's help to do
> > > this.
> > > 
> > > Since the concept of a container is entirely a userspace concept, a
> > > registration from the userspace container orchestration system initiates
> > > this.  This will define a point in time and a set of resources
> > > associated with a particular container with an audit container ID.
> > > 
> > > The registration is a pseudo filesystem (proc, since PID tree already
> > > exists) write of a u8[16] UUID representing the container ID to a file
> > > representing a process that will become the first process in a new
> > > container.  This write might place restrictions on mount namespaces
> > > required to define a container, or at least careful checking of
> > > namespaces in the kernel to verify permissions of the orchestrator so it
> > > can't change its own container ID.  A bind mount of nsfs may be
> > > necessary in the container orchestrator's mntNS.
> > > Note: Use a 128-bit scalar rather than a string to make compares faster
> > > and simpler.
> > > 
> > > Require a new CAP_CONTAINER_ADMIN to be able to carry out the
> > > registration.
> > 
> > Hang on. If containers are a user space concept, how can
> > you want CAP_CONTAINER_ANYTHING? If there's not such thing as
> > a container, how can you be asking for a capability to manage
> > them?
> 
> There is such a thing, but the kernel doesn't know about it yet.  This
> same situation exists for loginuid and sessionid which are userspace
> concepts that the kernel tracks for the convenience of userspace.  As
> for its name, I'm not particularly picky, so if you don't like
> CAP_CONTAINER_* then I'm fine with CAP_AUDIT_CONTAINERID.  It really
> needs to be distinct from CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL since we
> don't want to give the ability to set a containerID to any process that
> is able to do audit logging (such as vsftpd) and similarly we don't want
> to give the orchestrator the ability to control the setup of the audit
> daemon.

A long time ago, we were debating what should guard against rouge processes 
from setting the loginuid. Casey argued that the ability to set the loginuid 
means they have the ability to control the audit trail. That means that it 
should be guarded by CAP_AUDIT_CONTROL. I think the same logic applies today. 

The ability to arbitrarily set a container ID means the process has the 
ability to indirectly control the audit trail.

-Steve