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

2018-03-12 Thread Richard Guy Briggs
On 2018-03-08 13:02, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 06:21 -0500, Richard Guy Briggs wrote:
> > On 2018-03-05 09:24, Mimi Zohar wrote:
> > > On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote:
> > > > On 2018-03-05 08:43, Mimi Zohar wrote:
> > > > > Hi Richard,
> > > > > 
> > > > > This patch has been compiled, but not runtime tested.
> > > > 
> > > > Ok, great, thank you.  I assume you are offering this patch to be
> > > > included in this patchset?
> > > 
> > > Yes, thank you.
> > > 
> > > > I'll have a look to see where it fits in the
> > > > IMA record.  It might be better if it were an AUDIT_CONTAINER_INFO
> > > > auxiliary record, but I'll have a look at the circumstances of the
> > > > event.  
> > 
> > I had a look at the context of this record to see if adding the contid
> > field to it made sense.  I think the only records for which the contid
> > field makes sense are the two newly proposed records, AUDIT_CONTAINER
> > which introduces the container ID and the and AUDIT_CONTAINER_INFO which
> > documents the presence of the container ID in a process event (or
> > process-less network event).  All others should use the auxiliary record
> > AUDIT_CONTAINER_INFO rather than include the contid field directly
> > itself.  There are several reasons for this including record length, the
> > ability to filter unwanted records, the difficulty of changing the order
> > of or removing fields in the future.
> > 
> > Syscalls get this information automatically if the container ID is set
> > for a task via the AUDIT_CONTAINER_INFO auxiliary record.  Generally a
> > syscall event is one that uses the task's audit_context while a
> > standalone event uses NULL or builds a local audit_context that is
> > discarded immediately after the local use.
> > 
> > Looking at the two cases of AUDIT_INTEGRITY_RULE record generation, it
> > appears that they should be split into two distinct audit record types.
> > 
> > The record created in ima_audit_measurement() is a syscall record that
> > could possibly stand on its own since the subject attributes are
> > present.  If it remains a syscall auxiliary record it will automatically
> > have the AUDIT_CONTAINER_INFO record accompany it anyways.  If it is
> > decided to detach it (which would save cpu/netlink/disk bandwidth but is
> > not recommended due to not wanting to throw away any other syscall
> > information or other involved records (PATH, CWD, etc...) then a local
> > audit_context would be created for the AUDIT_INTEGRITY_RULE and
> > AUDIT_CONTAINERID_INFO records only and immediately discarded.
> > 
> > The record created in ima_parse_rule() is not currently a syscall record
> > since it is passed an audit_context of NULL and it has a very different
> > format that does not include any subject attributes (except subj_*=).
> > At first glance it appears this one should be a syscall accompanied
> > auxiliary record.  Either way it should have an AUDIT_CONTAINER_INFO
> > auxiliary record either by being converted to a syscall auxiliary record
> > by using current->audit_context rather than NULL when calling
> > audit_log_start(), or creating a local audit_context and calling
> > 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
> > 
> > Can you briefly describe the circumstances under which these two
> > different identically-numbered records are produced as a first step
> > towards splitting them into two distict records?
> 
> Agreed, the two uses should really be separated.  ima_parse_rule()
> generates audit messages, when the IMA policy is initially loaded,
> replaced, or extended, the policy rules are included in the audit log.
> When IMA is namespaced, there will be a host policy and namespace
> policies.  We'll need to be able differentiate between the host policy
> rules and IMA namespaced policy rules, and between IMA namespaced
> policy rules.

I would argue this type of message/record should be converted to an
accompanied syscall record, or have the subject attributes added to the
record so that it is clear what user/process initiated this action.  It
now occurs to me that to save audit communications and disk bandwidth,
one syscall record could accompany all the rule records, but if the list
is long enough it might overwhelm userspace audit event parsing code.
Steve?

Regardless, the ima_parse_rule() record format needs to be fixed to
address the non-standard use of "<" and ">" operators instead of the
standard "=" field/value separator.

> The audit messages produced by ima_audit_measurement() were originally
> upstreamed for forensics, and as seen by the FireEye blog are now used
> to augment existing security analytics.  These records are probably
> being used independently of any other audit records.  A single record
> is generated per file, per system.  With IMA namespacing, these
> records 

Re: audit events w/o audit rules?

2018-03-12 Thread Richard Guy Briggs
On 2018-03-12 22:30, Steve Grubb wrote:
> On Mon, 12 Mar 2018 11:55:32 -0700
> Todd Heberlein  wrote:
> 
> > Following the poor practice of replying to my own email :(
> > 
> > Apparently most of the data in audit.log is associated with PAM
> > auditing.
> > 
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-configuring_pam_for_auditing#sec-configuring_pam_tty_audit
> tps://www.redhat.com/mailman/listinfo/linux-audit  
> 
> There are hardwired events (events that show up no matter what the
> rules say) that come from things that are required. For example: logins,
> logouts, adding a user, deleting a user, changing a password, etc. These
> are usually documented in our STIG rules saying this requirement is met
> due to hardwired events.

To add to what Steve said, if you are really certain you don't want to
see certain types of events/records, you can create exclude rules to
drop them.  Some of the events are kernel-generated and some are
user-generated.

> -Steve

- 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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


Re: audit events w/o audit rules?

2018-03-12 Thread Steve Grubb
On Mon, 12 Mar 2018 11:55:32 -0700
Todd Heberlein  wrote:

> Following the poor practice of replying to my own email :(
> 
> Apparently most of the data in audit.log is associated with PAM
> auditing.
> 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-configuring_pam_for_auditing#sec-configuring_pam_tty_audit
tps://www.redhat.com/mailman/listinfo/linux-audit  

There are hardwired events (events that show up no matter what the
rules say) that come from things that are required. For example: logins,
logouts, adding a user, deleting a user, changing a password, etc. These
are usually documented in our STIG rules saying this requirement is met
due to hardwired events.

-Steve

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


Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread kbuild test robot
Hi Richard,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180309]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Richard-Guy-Briggs/audit-address-ANOM_LINK-excess-records/20180313-015527
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: the 
linux-review/Richard-Guy-Briggs/audit-address-ANOM_LINK-excess-records/20180313-015527
 HEAD 12e8c56bcd359f7d20d4ae011674d37bc832bc4c builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   fs/namei.c: In function 'may_follow_link':
>> fs/namei.c:929:2: error: too many arguments to function 
>> 'audit_log_link_denied'
 audit_log_link_denied("follow_link", >stack[0].link);
 ^
   In file included from include/linux/fsnotify.h:16:0,
from fs/namei.c:25:
   include/linux/audit.h:196:20: note: declared here
static inline void audit_log_link_denied(const char *string)
   ^

vim +/audit_log_link_denied +929 fs/namei.c

800179c9b Kees Cook 2012-07-25  886  
800179c9b Kees Cook 2012-07-25  887  /**
800179c9b Kees Cook 2012-07-25  888   * may_follow_link - Check symlink 
following for unsafe situations
55852635a Randy Dunlap  2012-08-18  889   * @nd: nameidata pathwalk data
800179c9b Kees Cook 2012-07-25  890   *
800179c9b Kees Cook 2012-07-25  891   * In the case of the 
sysctl_protected_symlinks sysctl being enabled,
800179c9b Kees Cook 2012-07-25  892   * CAP_DAC_OVERRIDE needs to be 
specifically ignored if the symlink is
800179c9b Kees Cook 2012-07-25  893   * in a sticky world-writable 
directory. This is to protect privileged
800179c9b Kees Cook 2012-07-25  894   * processes from failing races 
against path names that may change out
800179c9b Kees Cook 2012-07-25  895   * from under them by way of other 
users creating malicious symlinks.
800179c9b Kees Cook 2012-07-25  896   * It will permit symlinks to be 
followed only when outside a sticky
800179c9b Kees Cook 2012-07-25  897   * world-writable directory, or 
when the uid of the symlink and follower
800179c9b Kees Cook 2012-07-25  898   * match, or when the directory 
owner matches the symlink's owner.
800179c9b Kees Cook 2012-07-25  899   *
800179c9b Kees Cook 2012-07-25  900   * Returns 0 if following the 
symlink is allowed, -ve on error.
800179c9b Kees Cook 2012-07-25  901   */
fec2fa24e Al Viro   2015-05-06  902  static inline int 
may_follow_link(struct nameidata *nd)
800179c9b Kees Cook 2012-07-25  903  {
800179c9b Kees Cook 2012-07-25  904 const struct inode *inode;
800179c9b Kees Cook 2012-07-25  905 const struct inode *parent;
2d7f9e2ad Seth Forshee  2016-04-26  906 kuid_t puid;
800179c9b Kees Cook 2012-07-25  907  
800179c9b Kees Cook 2012-07-25  908 if (!sysctl_protected_symlinks)
800179c9b Kees Cook 2012-07-25  909 return 0;
800179c9b Kees Cook 2012-07-25  910  
800179c9b Kees Cook 2012-07-25  911 /* Allowed if owner and 
follower match. */
fceef393a Al Viro   2015-12-29  912 inode = nd->link_inode;
81abe27b1 Eric W. Biederman 2012-08-03  913 if 
(uid_eq(current_cred()->fsuid, inode->i_uid))
800179c9b Kees Cook 2012-07-25  914 return 0;
800179c9b Kees Cook 2012-07-25  915  
800179c9b Kees Cook 2012-07-25  916 /* Allowed if parent directory 
not sticky and world-writable. */
aa65fa35b Al Viro   2015-08-04  917 parent = nd->inode;
800179c9b Kees Cook 2012-07-25  918 if ((parent->i_mode & 
(S_ISVTX|S_IWOTH)) != (S_ISVTX|S_IWOTH))
800179c9b Kees Cook 2012-07-25  919 return 0;
800179c9b Kees Cook 2012-07-25  920  
800179c9b Kees Cook 2012-07-25  921 /* Allowed if parent directory 
and link owner match. */
2d7f9e2ad Seth Forshee  2016-04-26  922 puid = parent->i_uid;
2d7f9e2ad Seth Forshee  2016-04-26  923 if (uid_valid(puid) && 
uid_eq(puid, inode->i_uid))
800179c9b Kees Cook 2012-07-25  924 return 0;
800179c9b Kees Cook 2012-07-25  925  
31956502d Al Viro   2015-05-07  926 if (nd->flags & LOOKUP_RCU)
31956502d Al Viro   2015-05-07  927 return -ECHILD;
31956502d Al Viro   2015-05-07  928  
1cf2665b5 Al Viro   2015-05-06 @929 
audit_log_link_denied("follow_link", >stack[0].link);
800179c9b Kees Cook 2012-07-25  930 return -EACCES;
800179c9b Kees Cook 2012-07-25  931  }
800179c9b Kees Cook 2012-07-25  

Re: audit events w/o audit rules?

2018-03-12 Thread Todd Heberlein
Following the poor practice of replying to my own email :(

Apparently most of the data in audit.log is associated with PAM auditing.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-configuring_pam_for_auditing#sec-configuring_pam_tty_audit

todd

> On Mar 12, 2018, at 11:16 AM, Todd Heberlein  wrote:
> 
> I am using a Linux system (RHEL 6.9) with no audit rules set:
> 
> $ sudo auditctl -l
> No rules
> 
> but some data is still populating the audit log file
> 
> /var/log/audit/audit.log
> 
> Are there processes (or kernel code) that generate their own audit events 
> that bypass the configured audit rules?
> 
> Thanks,
> 
> Todd
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

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

audit events w/o audit rules?

2018-03-12 Thread Todd Heberlein
I am using a Linux system (RHEL 6.9) with no audit rules set:

$ sudo auditctl -l
No rules

but some data is still populating the audit log file

/var/log/audit/audit.log

Are there processes (or kernel code) that generate their own audit events that 
bypass the configured audit rules?

Thanks,

Todd

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

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

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 11:52 AM, 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.
>
> I'd just include it for completeness unless Steve thinks it will stand
> on its own and doesn't want the overhead.

If that's the argument, I'd rather just include it.  We've been burned
by not including stuff in the past and fixing those omissions has
proven to be a major source of contention.

-- 
paul moore
www.paul-moore.com

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


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

2018-03-12 Thread Richard Guy Briggs
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.

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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 11:30 AM, Richard Guy Briggs  wrote:
> On 2018-03-12 11:05, Paul Moore wrote:
>> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs  wrote:
>> > Audit link denied events generate duplicate PATH records which disagree
>> > in different ways from symlink and hardlink denials.
>> > audit_log_link_denied() should not directly generate PATH records.
>> > While we're at it, remove the now useless struct path argument.
>> >
>> > See: https://github.com/linux-audit/audit-kernel/issues/21
>> > Signed-off-by: Richard Guy Briggs 
>> > ---
>> >  fs/namei.c|  2 +-
>> >  include/linux/audit.h |  6 ++
>> >  kernel/audit.c| 17 ++---
>> >  3 files changed, 5 insertions(+), 20 deletions(-)
>>
>> I have no objection to the v2 change of removing the link parameter,
>> but this patch can not be merged as-is because the v1 patch has
>> already been merged into audit/next (as stated on the mailing list).
>
> Yes, I self-NACKed that patch.
>
> https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html
>
> Is it not possible to drop it, or would you have to do a revert to avoid
> a rebase?

Yes, it is possible to drop a patch from the audit/next patch stack,
but dropping patches is considered *very* bad form and not something I
want to do without a Very Good Reason.  While the v2 patch is the
"right" patch, the v1 patch is not dangerous, so I would rather you
just build on top of what is currently in audit/next.

-- 
paul moore
www.paul-moore.com

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


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

2018-03-12 Thread Paul Moore
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.

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



-- 
paul moore
www.paul-moore.com

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


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

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 11:17 AM, Steve Grubb  wrote:
> 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.

As discussed previously, I'm not going to merge any patches which
remove fields from existing records.

-- 
paul moore
www.paul-moore.com

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


Re: [RFC PATCH ghak21 4/4] audit: add parent of refused symlink to audit_names

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 3:59 AM, Richard Guy Briggs  wrote:
> On 2018-03-08 19:50, Paul Moore wrote:

...

>> (Point #2 is why I didn't merge patch 3/4, just include it in this
>> revised patch)
>
> On reviewing this, I'm not totally convinced the parent record is
> necessary to fully understand what happenned since there is a CWD
> record.  I left 3 and 4 as seperate patches in case it is found that
> only 3 is necessary.

You need to figure this out and decide what is necessary.

-- 
paul moore
www.paul-moore.com

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


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

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs  wrote:
> Audit link denied events for symlinks were missing the parent PATH
> record.  Add it.  Since the full pathname may not be available,
> reconstruct it from the path in the nameidata supplied.
>
> See: https://github.com/linux-audit/audit-kernel/issues/21
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/namei.c|  2 +-
>  include/linux/audit.h |  3 +++
>  kernel/audit.c| 31 +++
>  3 files changed, 35 insertions(+), 1 deletion(-)

See my comment in patch 3/4; it should really be folded into this
patch.  Additional comment inline below ...

> diff --git a/kernel/audit.c b/kernel/audit.c
> index e54deaf..4acf374 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -73,6 +73,7 @@
>  #include 
>  #include 
>  #include 
> +#include  /* for LOOKUP_PARENT */
>
>  #include "audit.h"
>
> @@ -2320,6 +2321,36 @@ void audit_log_link_denied(const char *operation)
> audit_log_end(ab);
>  }
>
> +/*
> + * audit_log_symlink_denied - report a symlink restriction denial
> + * @link: the path that triggered the restriction
> + */
> +void audit_log_symlink_denied(const struct path *link)
> +{
> +   char *pathname;
> +   struct filename *filename;
> +
> +   if (audit_dummy_context())
> +   return;
> +
> +   pathname = kmalloc(PATH_MAX + 1, GFP_KERNEL);
> +   if (!pathname) {
> +   audit_panic("memory allocation error while reporting symlink 
> denied");
> +   return;
> +   }
> +   filename = getname_kernel(d_absolute_path(link, pathname, PATH_MAX + 
> 1));
> +   if (IS_ERR(filename)) {
> +   audit_panic("error getting pathname while reporting symlink 
> denied");
> +   goto out;
> +   }
> +   audit_inode(filename, link->dentry->d_parent, LOOKUP_PARENT);

Since we are already checking audit_dummy_context() above we don't
need to check it again in audit_inode(), you should just call
__audit_inode() directly.  As a reminder, make sure you convert
LOOKUP_PARENT to AUDIT_INODE_PARENT.

> +   audit_log_link_denied("follow_link");
> +   putname(filename);
> +out:
> +   kfree(pathname);
> +   return;
> +}

-- 
paul moore
www.paul-moore.com

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


Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread Richard Guy Briggs
On 2018-03-12 11:05, Paul Moore wrote:
> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs  wrote:
> > Audit link denied events generate duplicate PATH records which disagree
> > in different ways from symlink and hardlink denials.
> > audit_log_link_denied() should not directly generate PATH records.
> > While we're at it, remove the now useless struct path argument.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  fs/namei.c|  2 +-
> >  include/linux/audit.h |  6 ++
> >  kernel/audit.c| 17 ++---
> >  3 files changed, 5 insertions(+), 20 deletions(-)
> 
> I have no objection to the v2 change of removing the link parameter,
> but this patch can not be merged as-is because the v1 patch has
> already been merged into audit/next (as stated on the mailing list).

Yes, I self-NACKed that patch.

https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html

Is it not possible to drop it, or would you have to do a revert to avoid
a rebase?

> You need to respin this patch against audit/next and redo the
> subject/description to indicate that you are just removing the unused
> link parameter in this updated patch.

So the way I had it in my devel tree rather than squashing it...

> > diff --git a/fs/namei.c b/fs/namei.c
> > index 9cc91fb..50d2533 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1011,7 +1011,7 @@ static int may_linkat(struct path *link)
> > if (safe_hardlink_source(inode) || inode_owner_or_capable(inode))
> > return 0;
> >
> > -   audit_log_link_denied("linkat", link);
> > +   audit_log_link_denied("linkat");
> > return -EPERM;
> >  }
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index af410d9..75d5b03 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -146,8 +146,7 @@ extern void audit_log_d_path(struct 
> > audit_buffer *ab,
> >  const struct path *path);
> >  extern voidaudit_log_key(struct audit_buffer *ab,
> >   char *key);
> > -extern voidaudit_log_link_denied(const char *operation,
> > - const struct path *link);
> > +extern voidaudit_log_link_denied(const char *operation);
> >  extern voidaudit_log_lost(const char *message);
> >
> >  extern int audit_log_task_context(struct audit_buffer *ab);
> > @@ -194,8 +193,7 @@ static inline void audit_log_d_path(struct audit_buffer 
> > *ab,
> >  { }
> >  static inline void audit_log_key(struct audit_buffer *ab, char *key)
> >  { }
> > -static inline void audit_log_link_denied(const char *string,
> > -const struct path *link)
> > +static inline void audit_log_link_denied(const char *string)
> >  { }
> >  static inline int audit_log_task_context(struct audit_buffer *ab)
> >  {
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 7026d69..e54deaf 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -2301,36 +2301,23 @@ void audit_log_task_info(struct audit_buffer *ab, 
> > struct task_struct *tsk)
> >  /**
> >   * audit_log_link_denied - report a link restriction denial
> >   * @operation: specific link operation
> > - * @link: the path that triggered the restriction
> >   */
> > -void audit_log_link_denied(const char *operation, const struct path *link)
> > +void audit_log_link_denied(const char *operation)
> >  {
> > struct audit_buffer *ab;
> > -   struct audit_names *name;
> >
> > if (!audit_enabled || audit_dummy_context())
> > return;
> >
> > -   name = kzalloc(sizeof(*name), GFP_NOFS);
> > -   if (!name)
> > -   return;
> > -
> > /* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
> > ab = audit_log_start(current->audit_context, GFP_KERNEL,
> >  AUDIT_ANOM_LINK);
> > if (!ab)
> > -   goto out;
> > +   return;
> > audit_log_format(ab, "op=%s", operation);
> > audit_log_task_info(ab, current);
> > audit_log_format(ab, " res=0");
> > audit_log_end(ab);
> > -
> > -   /* Generate AUDIT_PATH record with object. */
> > -   name->type = AUDIT_TYPE_NORMAL;
> > -   audit_copy_inode(name, link->dentry, d_backing_inode(link->dentry));
> > -   audit_log_name(current->audit_context, name, link, 0, NULL);
> > -out:
> > -   kfree(name);
> >  }
> >
> >  /**
> > --
> > 1.8.3.1
> >
> 
> 
> 
> -- 
> paul moore
> www.paul-moore.com
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, 

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

2018-03-12 Thread Richard Guy Briggs
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

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

--
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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


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

2018-03-12 Thread 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(-)
> 

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


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

2018-03-12 Thread Paul Moore
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?

> 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;
>  }
> --
> 1.8.3.1

-- 
paul moore
www.paul-moore.com

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


Re: [PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread Paul Moore
On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs  wrote:
> Audit link denied events generate duplicate PATH records which disagree
> in different ways from symlink and hardlink denials.
> audit_log_link_denied() should not directly generate PATH records.
> While we're at it, remove the now useless struct path argument.
>
> See: https://github.com/linux-audit/audit-kernel/issues/21
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/namei.c|  2 +-
>  include/linux/audit.h |  6 ++
>  kernel/audit.c| 17 ++---
>  3 files changed, 5 insertions(+), 20 deletions(-)

I have no objection to the v2 change of removing the link parameter,
but this patch can not be merged as-is because the v1 patch has
already been merged into audit/next (as stated on the mailing list).
You need to respin this patch against audit/next and redo the
subject/description to indicate that you are just removing the unused
link parameter in this updated patch.

> diff --git a/fs/namei.c b/fs/namei.c
> index 9cc91fb..50d2533 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1011,7 +1011,7 @@ static int may_linkat(struct path *link)
> if (safe_hardlink_source(inode) || inode_owner_or_capable(inode))
> return 0;
>
> -   audit_log_link_denied("linkat", link);
> +   audit_log_link_denied("linkat");
> return -EPERM;
>  }
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..75d5b03 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -146,8 +146,7 @@ extern void audit_log_d_path(struct 
> audit_buffer *ab,
>  const struct path *path);
>  extern voidaudit_log_key(struct audit_buffer *ab,
>   char *key);
> -extern voidaudit_log_link_denied(const char *operation,
> - const struct path *link);
> +extern voidaudit_log_link_denied(const char *operation);
>  extern voidaudit_log_lost(const char *message);
>
>  extern int audit_log_task_context(struct audit_buffer *ab);
> @@ -194,8 +193,7 @@ static inline void audit_log_d_path(struct audit_buffer 
> *ab,
>  { }
>  static inline void audit_log_key(struct audit_buffer *ab, char *key)
>  { }
> -static inline void audit_log_link_denied(const char *string,
> -const struct path *link)
> +static inline void audit_log_link_denied(const char *string)
>  { }
>  static inline int audit_log_task_context(struct audit_buffer *ab)
>  {
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 7026d69..e54deaf 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -2301,36 +2301,23 @@ void audit_log_task_info(struct audit_buffer *ab, 
> struct task_struct *tsk)
>  /**
>   * audit_log_link_denied - report a link restriction denial
>   * @operation: specific link operation
> - * @link: the path that triggered the restriction
>   */
> -void audit_log_link_denied(const char *operation, const struct path *link)
> +void audit_log_link_denied(const char *operation)
>  {
> struct audit_buffer *ab;
> -   struct audit_names *name;
>
> if (!audit_enabled || audit_dummy_context())
> return;
>
> -   name = kzalloc(sizeof(*name), GFP_NOFS);
> -   if (!name)
> -   return;
> -
> /* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
> ab = audit_log_start(current->audit_context, GFP_KERNEL,
>  AUDIT_ANOM_LINK);
> if (!ab)
> -   goto out;
> +   return;
> audit_log_format(ab, "op=%s", operation);
> audit_log_task_info(ab, current);
> audit_log_format(ab, " res=0");
> audit_log_end(ab);
> -
> -   /* Generate AUDIT_PATH record with object. */
> -   name->type = AUDIT_TYPE_NORMAL;
> -   audit_copy_inode(name, link->dentry, d_backing_inode(link->dentry));
> -   audit_log_name(current->audit_context, name, link, 0, NULL);
> -out:
> -   kfree(name);
>  }
>
>  /**
> --
> 1.8.3.1
>



-- 
paul moore
www.paul-moore.com

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


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

2018-03-12 Thread Richard Guy Briggs
On 2018-03-12 02:31, 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 
> 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(-)
> 
> -- 

Changelog:
v2:
- remove now supperfluous struct path * parameter from audit_log_link_denied()
- refactor audit_log_symlink_denied() to properly free memory (pathname, 
filename)

> 1.8.3.1
> 

- 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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


Re: [RFC PATCH ghak21 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread Richard Guy Briggs
On 2018-03-08 19:26, Paul Moore wrote:
> On Wed, Feb 14, 2018 at 11:18 AM, Richard Guy Briggs  wrote:
> > Audit link denied events generate duplicate PATH records which disagree
> > in different ways from symlink and hardlink denials.
> > audit_log_link_denied() should not directly generate PATH records.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  kernel/audit.c | 14 +-
> >  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> Merged, thanks.

Self-NACK.  Please un-merge this RFC v1 version and merge instead the v2
patch since it removes the now-unnecessary struct path * parameter from
audit_log_link_denied().

> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 4c3fd24..683b249 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -2259,31 +2259,19 @@ void audit_log_task_info(struct audit_buffer *ab, 
> > struct task_struct *tsk)
> >  void audit_log_link_denied(const char *operation, const struct path *link)
> >  {
> > struct audit_buffer *ab;
> > -   struct audit_names *name;
> >
> > if (!audit_enabled || audit_dummy_context())
> > return;
> >
> > -   name = kzalloc(sizeof(*name), GFP_NOFS);
> > -   if (!name)
> > -   return;
> > -
> > /* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
> > ab = audit_log_start(current->audit_context, GFP_KERNEL,
> >  AUDIT_ANOM_LINK);
> > if (!ab)
> > -   goto out;
> > +   return;
> > audit_log_format(ab, "op=%s", operation);
> > audit_log_task_info(ab, current);
> > audit_log_format(ab, " res=0");
> > audit_log_end(ab);
> > -
> > -   /* Generate AUDIT_PATH record with object. */
> > -   name->type = AUDIT_TYPE_NORMAL;
> > -   audit_copy_inode(name, link->dentry, d_backing_inode(link->dentry));
> > -   audit_log_name(current->audit_context, name, link, 0, NULL);
> > -out:
> > -   kfree(name);
> >  }
> >
> >  /**
> > --
> > 1.8.3.1
> >
> 
> 
> 
> -- 
> paul moore
> www.paul-moore.com

- 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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


Re: [RFC PATCH ghak21 4/4] audit: add parent of refused symlink to audit_names

2018-03-12 Thread Richard Guy Briggs
On 2018-03-08 19:50, Paul Moore wrote:
> On Wed, Feb 14, 2018 at 11:18 AM, Richard Guy Briggs  wrote:
> > Audit link denied events for symlinks were missing the parent PATH
> > record.  Add it.  Since the full pathname may not be available,
> > reconstruct it from the path in the nameidata supplied.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  fs/namei.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 0edf133..bf1c046b 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -923,6 +923,7 @@ static inline int may_follow_link(struct nameidata *nd)
> > const struct inode *inode;
> > const struct inode *parent;
> > kuid_t puid;
> > +   char *pathname;
> >
> > if (!sysctl_protected_symlinks)
> > return 0;
> > @@ -945,6 +946,14 @@ static inline int may_follow_link(struct nameidata *nd)
> > if (nd->flags & LOOKUP_RCU)
> > return -ECHILD;
> >
> > +   pathname = kmalloc(PATH_MAX + 1, GFP_KERNEL);
> > +   if (!pathname)
> > +   return -ENOMEM;
> 
> Two things here:
> 
> 1. We need to allocate a buffer to feed to d_absolute_path(), and
> getname_kernel() is just going to make another copy so we need to make
> sure we clean up after ourselves.  Perhaps I missing it, but I'm not
> seeing where we free the kmalloc'd buffer or call putname().  Feel
> free to correct me if I'm missing something obvious.

That is put very diplomatically!  Both fixed, with audit_panic() as
needed.

> 2. While the audit_* calls are going to bail early in the cases where
> audit is disabled, or not configured, we are going to pay the penalty
> for the kmalloc() call above, as well as the getname_kernel() and
> d_absolute_path() calls below.  I think it might be beneficial to
> create a new function (audit_log_symlink_denied() perhaps?) which
> encapsulates all the audit bits in may_follow_link() and exits early
> when needed.  What do you think?

I agree a seperate function is appropriate.  There was some back and
forth between namei.c and audit.c due to struct nameidata and
audit_panic() not able to co-exist due to them both being local to their
respective sub-systems.

> (Point #2 is why I didn't merge patch 3/4, just include it in this
> revised patch)

On reviewing this, I'm not totally convinced the parent record is
necessary to fully understand what happenned since there is a CWD
record.  I left 3 and 4 as seperate patches in case it is found that
only 3 is necessary.

> > +   audit_inode(getname_kernel(d_absolute_path(>stack[0].link, 
> > pathname,
> > +  PATH_MAX + 1)),
> > +   nd->stack[0].link.dentry, 0);
> > +   audit_inode(nd->name, nd->stack[0].link.dentry->d_parent, 
> > LOOKUP_PARENT);
> > +
> > audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > audit_log_link_denied("follow_link", >stack[0].link);
> >
> > return -EACCES;
> > --
> > 1.8.3.1
> 
> -- 
> paul moore
> www.paul-moore.com

- 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-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


[PATCH ghak21 V2 1/4] audit: make ANOM_LINK obey audit_enabled and audit_dummy_context

2018-03-12 Thread Richard Guy Briggs
Audit link denied events emit disjointed records when audit is disabled.
No records should be emitted when audit is disabled.

See: https://github.com/linux-audit/audit-kernel/issues/21
Signed-off-by: Richard Guy Briggs 
---
 kernel/audit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/audit.c b/kernel/audit.c
index 1a3e75d..7026d69 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2308,6 +2308,9 @@ void audit_log_link_denied(const char *operation, const 
struct path *link)
struct audit_buffer *ab;
struct audit_names *name;
 
+   if (!audit_enabled || audit_dummy_context())
+   return;
+
name = kzalloc(sizeof(*name), GFP_NOFS);
if (!name)
return;
-- 
1.8.3.1

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


[PATCH ghak21 V2 4/4] audit: add parent of refused symlink to audit_names

2018-03-12 Thread Richard Guy Briggs
Audit link denied events for symlinks were missing the parent PATH
record.  Add it.  Since the full pathname may not be available,
reconstruct it from the path in the nameidata supplied.

See: https://github.com/linux-audit/audit-kernel/issues/21
Signed-off-by: Richard Guy Briggs 
---
 fs/namei.c|  2 +-
 include/linux/audit.h |  3 +++
 kernel/audit.c| 31 +++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/fs/namei.c b/fs/namei.c
index 00f5041..2f39617 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -946,7 +946,7 @@ static inline int may_follow_link(struct nameidata *nd)
return -ECHILD;
 
audit_inode(nd->name, nd->stack[0].link.dentry, 0);
-   audit_log_link_denied("follow_link", >stack[0].link);
+   audit_log_symlink_denied(>stack[0].link);
return -EACCES;
 }
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 75d5b03..b5808e9 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -147,6 +147,7 @@ extern void audit_log_d_path(struct 
audit_buffer *ab,
 extern voidaudit_log_key(struct audit_buffer *ab,
  char *key);
 extern voidaudit_log_link_denied(const char *operation);
+extern voidaudit_log_symlink_denied(const struct path *link);
 extern voidaudit_log_lost(const char *message);
 
 extern int audit_log_task_context(struct audit_buffer *ab);
@@ -195,6 +196,8 @@ static inline void audit_log_key(struct audit_buffer *ab, 
char *key)
 { }
 static inline void audit_log_link_denied(const char *string)
 { }
+static inline void audit_log_symlink_denied(const struct path *link)
+{ }
 static inline int audit_log_task_context(struct audit_buffer *ab)
 {
return 0;
diff --git a/kernel/audit.c b/kernel/audit.c
index e54deaf..4acf374 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include  /* for LOOKUP_PARENT */
 
 #include "audit.h"
 
@@ -2320,6 +2321,36 @@ void audit_log_link_denied(const char *operation)
audit_log_end(ab);
 }
 
+/*
+ * audit_log_symlink_denied - report a symlink restriction denial
+ * @link: the path that triggered the restriction
+ */
+void audit_log_symlink_denied(const struct path *link)
+{
+   char *pathname;
+   struct filename *filename;
+
+   if (audit_dummy_context())
+   return;
+
+   pathname = kmalloc(PATH_MAX + 1, GFP_KERNEL);
+   if (!pathname) {
+   audit_panic("memory allocation error while reporting symlink 
denied");
+   return;
+   }
+   filename = getname_kernel(d_absolute_path(link, pathname, PATH_MAX + 
1));
+   if (IS_ERR(filename)) {
+   audit_panic("error getting pathname while reporting symlink 
denied");
+   goto out;
+   }
+   audit_inode(filename, link->dentry->d_parent, LOOKUP_PARENT);
+   audit_log_link_denied("follow_link");
+   putname(filename);
+out:
+   kfree(pathname);
+   return;
+}
+
 /**
  * audit_log_end - end one audit record
  * @ab: the audit_buffer
-- 
1.8.3.1

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


[PATCH ghak21 V2 2/4] audit: link denied should not directly generate PATH record

2018-03-12 Thread Richard Guy Briggs
Audit link denied events generate duplicate PATH records which disagree
in different ways from symlink and hardlink denials.
audit_log_link_denied() should not directly generate PATH records.
While we're at it, remove the now useless struct path argument.

See: https://github.com/linux-audit/audit-kernel/issues/21
Signed-off-by: Richard Guy Briggs 
---
 fs/namei.c|  2 +-
 include/linux/audit.h |  6 ++
 kernel/audit.c| 17 ++---
 3 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 9cc91fb..50d2533 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1011,7 +1011,7 @@ static int may_linkat(struct path *link)
if (safe_hardlink_source(inode) || inode_owner_or_capable(inode))
return 0;
 
-   audit_log_link_denied("linkat", link);
+   audit_log_link_denied("linkat");
return -EPERM;
 }
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index af410d9..75d5b03 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -146,8 +146,7 @@ extern void audit_log_d_path(struct 
audit_buffer *ab,
 const struct path *path);
 extern voidaudit_log_key(struct audit_buffer *ab,
  char *key);
-extern voidaudit_log_link_denied(const char *operation,
- const struct path *link);
+extern voidaudit_log_link_denied(const char *operation);
 extern voidaudit_log_lost(const char *message);
 
 extern int audit_log_task_context(struct audit_buffer *ab);
@@ -194,8 +193,7 @@ static inline void audit_log_d_path(struct audit_buffer *ab,
 { }
 static inline void audit_log_key(struct audit_buffer *ab, char *key)
 { }
-static inline void audit_log_link_denied(const char *string,
-const struct path *link)
+static inline void audit_log_link_denied(const char *string)
 { }
 static inline int audit_log_task_context(struct audit_buffer *ab)
 {
diff --git a/kernel/audit.c b/kernel/audit.c
index 7026d69..e54deaf 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2301,36 +2301,23 @@ void audit_log_task_info(struct audit_buffer *ab, 
struct task_struct *tsk)
 /**
  * audit_log_link_denied - report a link restriction denial
  * @operation: specific link operation
- * @link: the path that triggered the restriction
  */
-void audit_log_link_denied(const char *operation, const struct path *link)
+void audit_log_link_denied(const char *operation)
 {
struct audit_buffer *ab;
-   struct audit_names *name;
 
if (!audit_enabled || audit_dummy_context())
return;
 
-   name = kzalloc(sizeof(*name), GFP_NOFS);
-   if (!name)
-   return;
-
/* Generate AUDIT_ANOM_LINK with subject, operation, outcome. */
ab = audit_log_start(current->audit_context, GFP_KERNEL,
 AUDIT_ANOM_LINK);
if (!ab)
-   goto out;
+   return;
audit_log_format(ab, "op=%s", operation);
audit_log_task_info(ab, current);
audit_log_format(ab, " res=0");
audit_log_end(ab);
-
-   /* Generate AUDIT_PATH record with object. */
-   name->type = AUDIT_TYPE_NORMAL;
-   audit_copy_inode(name, link->dentry, d_backing_inode(link->dentry));
-   audit_log_name(current->audit_context, name, link, 0, NULL);
-out:
-   kfree(name);
 }
 
 /**
-- 
1.8.3.1

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


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

2018-03-12 Thread Richard Guy Briggs
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(+)

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;
 }
-- 
1.8.3.1

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


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

2018-03-12 Thread Richard Guy Briggs
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 
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(-)

-- 
1.8.3.1

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