Re: Monitoring files

2018-04-24 Thread Steve Grubb 
On Tuesday, April 24, 2018 9:12:49 PM EDT warron.french wrote:
> Steve, I did a search on the manpage for auditctl and there was no
> references to any -i switch;
>of course it could be because the version we are on might be too old in
> comparison.

This is what the auditctl man page says from audit-1.0.16:

-i Ignore errors when reading rules from a file

I hope you are not using anything less than that.

-Steve


> On Tue, Apr 24, 2018 at 8:43 PM, Richard Guy Briggs  wrote:
> > On 2018-04-24 18:04, warron.french wrote:
> > > Furthermore, where would I add the -i switch to a rule like this one:
> > > 
> > > -a always,exit -F path=/usr/bin/cgclassify -F perm=x -F auid>=1000 -F
> > > auid!=4294967295 -k privileged
> > 
> > I'm not aware of any per-rule switches to permit failure to load to be
> > non-fatal.  I was suggesting it might help in your situation to add such
> > a feature, but I think the better solution is a customized rule set for
> > each machine or type of machine.
> > 
> > > ??
> > > 
> > > --
> > > Warron French
> > > 
> > > 
> > > On Tue, Apr 24, 2018 at 6:03 PM, warron.french
> > > 
> > > 
> > > wrote:
> > > > Mr. Briggs/Rafi,
> > > > 
> > > > I don't see the -i switch even mentioned in the manpage for
> > 
> > audit.rules.
> > 
> > > > Is this a documented switch, or not yet a capability on Red Hat or
> > 
> > CentOS
> > 
> > > > systems?
> > > > 
> > > > Thanks in advance,
> > > > 
> > > > --
> > > > Warron French
> > > > 
> > > > 
> > > > On Tue, Apr 24, 2018 at 11:14 AM, Richard Guy Briggs 
> > > > 
> > > > wrote:
> > > >> On 2018-04-23 23:41, F Rafi wrote:
> > > >> > Adding a -i to the rules file should ignore any errors.
> > > >> 
> > > >> At risk of feature creep, it might be nice to have a flag to ignore
> > > >> certain rules but not others, a way to tag individual rules with
> > 
> > either
> > 
> > > >> a must, or a different tag with "ignore if not present" for file
> > 
> > rules.
> > 
> > > >> > -Farhan
> > > >> > 
> > > >> > On Mon, Apr 23, 2018 at 9:19 PM, warron.french <
> > 
> > warron.fre...@gmail.com>
> > 
> > > >> wrote:
> > > >> > > Hi, I have a requirement to monitor a ton of files, executables
> > 
> > and
> > 
> > > >> confug
> > > >> 
> > > >> > > files.
> > > >> > > 
> > > >> > > Anyway, not all of my systems have every file in the list; and
> > 
> > when I
> > 
> > > >> add
> > > >> 
> > > >> > > the rules appropriate, either as a Watch (-w) rule or as an
> > > >> > > Action
> > > >> 
> > > >> (-a)
> > > >> 
> > > >> > > rule, the rules stop loading when the find a rule that has a
> > > >> > > file
> > 
> > that
> > 
> > > >> > > doesn't exist *on that particular system*.
> > > >> > > 
> > > >> > > This is the intended effect, yes?
> > > >> > > 
> > > >> > > Thanks in advance,
> > > >> > > --
> > > >> > > Warron French
> > > >> 
> > > >> - 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




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

Re: Monitoring files

2018-04-24 Thread warron.french 
Steve, I did a search on the manpage for auditctl and there was no
references to any -i switch;
   of course it could be because the version we are on might be too old in
comparison.


--
Warron French


On Tue, Apr 24, 2018 at 8:43 PM, Richard Guy Briggs  wrote:

> On 2018-04-24 18:04, warron.french wrote:
> > Furthermore, where would I add the -i switch to a rule like this one:
> >
> > -a always,exit -F path=/usr/bin/cgclassify -F perm=x -F auid>=1000 -F
> > auid!=4294967295 -k privileged
>
> I'm not aware of any per-rule switches to permit failure to load to be
> non-fatal.  I was suggesting it might help in your situation to add such
> a feature, but I think the better solution is a customized rule set for
> each machine or type of machine.
>
> > ??
> >
> > --
> > Warron French
> >
> >
> > On Tue, Apr 24, 2018 at 6:03 PM, warron.french 
> > wrote:
> >
> > > Mr. Briggs/Rafi,
> > >
> > > I don't see the -i switch even mentioned in the manpage for
> audit.rules.
> > > Is this a documented switch, or not yet a capability on Red Hat or
> CentOS
> > > systems?
> > >
> > > Thanks in advance,
> > >
> > > --
> > > Warron French
> > >
> > >
> > > On Tue, Apr 24, 2018 at 11:14 AM, Richard Guy Briggs 
> > > wrote:
> > >
> > >> On 2018-04-23 23:41, F Rafi wrote:
> > >> > Adding a -i to the rules file should ignore any errors.
> > >>
> > >> At risk of feature creep, it might be nice to have a flag to ignore
> > >> certain rules but not others, a way to tag individual rules with
> either
> > >> a must, or a different tag with "ignore if not present" for file
> rules.
> > >>
> > >> > -Farhan
> > >> >
> > >> > On Mon, Apr 23, 2018 at 9:19 PM, warron.french <
> warron.fre...@gmail.com>
> > >> wrote:
> > >> > > Hi, I have a requirement to monitor a ton of files, executables
> and
> > >> confug
> > >> > > files.
> > >> > >
> > >> > > Anyway, not all of my systems have every file in the list; and
> when I
> > >> add
> > >> > > the rules appropriate, either as a Watch (-w) rule or as an Action
> > >> (-a)
> > >> > > rule, the rules stop loading when the find a rule that has a file
> that
> > >> > > doesn't exist *on that particular system*.
> > >> > >
> > >> > > This is the intended effect, yes?
> > >> > >
> > >> > > Thanks in advance,
> > >> > > --
> > >> > > Warron French
> > >>
> > >> - 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
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Monitoring files

2018-04-24 Thread Richard Guy Briggs 
On 2018-04-24 18:04, warron.french wrote:
> Furthermore, where would I add the -i switch to a rule like this one:
> 
> -a always,exit -F path=/usr/bin/cgclassify -F perm=x -F auid>=1000 -F
> auid!=4294967295 -k privileged

I'm not aware of any per-rule switches to permit failure to load to be
non-fatal.  I was suggesting it might help in your situation to add such
a feature, but I think the better solution is a customized rule set for
each machine or type of machine.

> ??
> 
> --
> Warron French
> 
> 
> On Tue, Apr 24, 2018 at 6:03 PM, warron.french 
> wrote:
> 
> > Mr. Briggs/Rafi,
> >
> > I don't see the -i switch even mentioned in the manpage for audit.rules.
> > Is this a documented switch, or not yet a capability on Red Hat or CentOS
> > systems?
> >
> > Thanks in advance,
> >
> > --
> > Warron French
> >
> >
> > On Tue, Apr 24, 2018 at 11:14 AM, Richard Guy Briggs 
> > wrote:
> >
> >> On 2018-04-23 23:41, F Rafi wrote:
> >> > Adding a -i to the rules file should ignore any errors.
> >>
> >> At risk of feature creep, it might be nice to have a flag to ignore
> >> certain rules but not others, a way to tag individual rules with either
> >> a must, or a different tag with "ignore if not present" for file rules.
> >>
> >> > -Farhan
> >> >
> >> > On Mon, Apr 23, 2018 at 9:19 PM, warron.french 
> >> wrote:
> >> > > Hi, I have a requirement to monitor a ton of files, executables and
> >> confug
> >> > > files.
> >> > >
> >> > > Anyway, not all of my systems have every file in the list; and when I
> >> add
> >> > > the rules appropriate, either as a Watch (-w) rule or as an Action
> >> (-a)
> >> > > rule, the rules stop loading when the find a rule that has a file that
> >> > > doesn't exist *on that particular system*.
> >> > >
> >> > > This is the intended effect, yes?
> >> > >
> >> > > Thanks in advance,
> >> > > --
> >> > > Warron French
> >>
> >> - 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

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

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

2018-04-24 Thread Richard Guy Briggs 
On 2018-04-24 15:01, Paul Moore wrote:
> On Mon, Apr 23, 2018 at 10:02 PM, Richard Guy Briggs  wrote:
> > On 2018-04-23 19:15, Paul Moore wrote:
> >> On Sat, Apr 21, 2018 at 10:34 AM, Richard Guy Briggs  
> >> wrote:
> >> > On 2018-04-18 19:47, Paul Moore wrote:
> >> >> On Fri, Mar 16, 2018 at 5:00 AM, 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 "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(-)
> 
> ...
> 
> >> >> >  /* audit_rule_data supports filter rules with both integer and string
> >> >> >   * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
> >> >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> >> >> > index 4e0a4ac..29c8482 100644
> >> >> > --- a/kernel/auditsc.c
> >> >> > +++ b/kernel/auditsc.c
> >> >> > @@ -2073,6 +2073,90 @@ int audit_set_loginuid(kuid_t loginuid)
> >> >> > return rc;
> >> >> >  }
> >> >> >
> >> >> > +static int audit_set_containerid_perm(struct task_struct *task, u64 
> >> >> > containerid)
> >> >> > +{
> >> >> > +   struct task_struct *parent;
> >> >> > +   u64 pcontainerid, ccontainerid;
> >> >> > +
> >> >> > +   /* Don't allow to set our own containerid */
> >> >> > +   if (current == task)
> >> >> > +   return -EPERM;
> >> >>
> >> >> Why not?  Is there some obvious security concern that I missing?
> >> >
> >> > We then lose the distinction in the AUDIT_CONTAINER record between the
> >> > initiating PID and the target PID.  This was outlined in the proposal.
> >>
> >> I just went back and reread the v3 proposal and I still don't see a
> >> good explanation of this.  Why is this bad?  What's the security
> >> concern?
> >
> > I don't remember, specifically.  Maybe this has been addressed by the
> > check for children/threads or identical parent container ID.  So, I'm
> > reluctantly willing to remove that check for now.
> 
> Okay.  For the record, if someone can explain to me why this
> restriction saves us from some terrible situation I'm all for leaving
> it.  I'm just opposed to restrictions without solid reasoning behind
> them.
> 
> >> > Having said that, I'm still not sure we have protected sufficiently from
> >> > a child turning around and setting it's parent's as yet unset or
> >> > inherited audit container ID.
> >>
> >> Yes, I believe we only want to let a task set the audit container for
> >> it's children (or itself/threads if we decide to allow that, see
> >> above).  There *has* to be a function to check to see if a task if a
> >> child of a given task ... right? ... although this is likely to be a
> >> pointer traversal and locking nightmare ... hmmm.
> >
> > Isn't that just (struct task_struct)parent == (struct
> > task_struct)child->parent (or ->real_parent)?
> >
> > And now that I say that, it is covered by the following patch's child
> > check, so as long as we keep that, we should be fine.
> 
> I was thinking of checking not just current's immediate children, but
> any of it's descendants as I believe that is what we want to limit,
> yes?  I

Re: Monitoring files

2018-04-24 Thread Steve Grubb 
On Tuesday, April 24, 2018 7:45:15 PM EDT warron.french wrote:
>  Mr. Briggs/Rafi,
> 
> I don't see the -i switch even mentioned in the manpage for audit.rules.
> Is this a documented switch, or not yet a capability on Red Hat or CentOS
> systems?

All audit commands are documented in the auditctl man page. When rules load, 
auditctl processes them as if you typed them in one by one via auditctl. Its 
just that you do not need to type auditctl on each line of the rules.

-Stev

> --
> Warron French
> 
> On Tue, Apr 24, 2018 at 6:31 PM, Richard Guy Briggs  wrote:
> > On 2018-04-24 18:03, warron.french wrote:
> > > Mr. Briggs/Rafi,
> > 
> > I think you forgot to reply to the list (preferred) and/or Rafi.
> > 
> > > I don't see the -i switch even mentioned in the manpage for
> > > audit.rules.
> > > Is this a documented switch, or not yet a capability on Red Hat or
> > > CentOS
> > > systems?
> > > 
> > > Thanks in advance,
> > > 
> > > --
> > > Warron French
> > > 
> > > 
> > > On Tue, Apr 24, 2018 at 11:14 AM, Richard Guy Briggs 
> > 
> > wrote:
> > > > On 2018-04-23 23:41, F Rafi wrote:
> > > > > Adding a -i to the rules file should ignore any errors.
> > > > 
> > > > At risk of feature creep, it might be nice to have a flag to ignore
> > > > certain rules but not others, a way to tag individual rules with
> > > > either
> > > > a must, or a different tag with "ignore if not present" for file
> > > > rules.
> > > > 
> > > > > -Farhan
> > > > > 
> > > > > On Mon, Apr 23, 2018 at 9:19 PM, warron.french <
> > 
> > warron.fre...@gmail.com>
> > 
> > > > wrote:
> > > > > > Hi, I have a requirement to monitor a ton of files, executables
> > > > > > and
> > > > 
> > > > confug
> > > > 
> > > > > > files.
> > > > > > 
> > > > > > Anyway, not all of my systems have every file in the list; and
> > 
> > when I
> > 
> > > > add
> > > > 
> > > > > > the rules appropriate, either as a Watch (-w) rule or as an
> > > > > > Action
> > 
> > (-a)
> > 
> > > > > > rule, the rules stop loading when the find a rule that has a file
> > 
> > that
> > 
> > > > > > doesn't exist *on that particular system*.
> > > > > > 
> > > > > > This is the intended effect, yes?
> > > > > > 
> > > > > > Thanks in advance,
> > > > > > --
> > > > > > Warron French
> > > > 
> > > > - 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




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

Re: Limiting SECCOMP audit events

2018-04-24 Thread Tyler Hicks 
On 04/17/2018 08:57 PM, Paul Moore wrote:
> On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb  wrote:
>> Hello,
>>
>> Ping?  SECCOMP events are still flooding the system. Can we do something
>> hackish to turn this off until a better solution can be created?
> 
> Pong?
> 
> The only workarounds I can think of would be to disable audit or
> create a filter rule excluding auditing for the noisy process.  I've
> never tried the latter, but I'm pretty sure it would work.

I've pushed two branches which have slightly different behaviors. They
only differ by the last patch in each branch. The tree is here:

https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/

1) seccomp-auditing/option-1-consistent-behavior
   This branch removes all special casing around audited processes. The
   decision on whether or not to audit an action no longer considers
   whether or not the process is being audited. RET_TRAP, RET_TRACE,
   and RET_ERRNO actions will only be logged if the application loads
   the filter with the SECCOMP_FILTER_FLAG_LOG bit set. The admin has
   the final say via the kernel.seccomp.actions_logged sysctl.

2) seccomp-auditing/option-2-honor-sysctl
   This branch continues to special case audited processes. The decision
   to log RET_TRAP, RET_TRACE, and RET_ERRNO actions depends on if the
   SECCOMP_FILTER_FLAG_LOG bit being set OR if the process is being
   audited. The admin has the final say via the
   kernel.seccomp.actions_logged sysctl.

I prefer option #1. Play with both implementations and let me know what
works best for your requirements. Both branches share the same
underlying patches for emitting audit records on writes to the
kernel.seccomp.actions_logged sysctl.

Tyler

> 
>> On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote:
>>> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks  wrote:
 On 01/02/2018 02:03 PM, Steve Grubb wrote:
> Hello,
>
> I know people have been busy with the holidays and things...but I just
> wanted to mention I'm still seeing 100's of thousands of seccomp events
> hitting the audit logs every day.
>
> # ausearch --start today -m seccomp --raw | aureport -x --summary
>
> Executable Summary Report
> =
> total  file
> =
> 209843  /usr/lib64/firefox/firefox
> 2196  /usr/lib64/qt5/libexec/QtWebEngineProcess
>
> Has anyone looked at it beyond pseudo code?

 I started to throw together a quick couple of patches prior to the
 holidays but didn't finish. Things aren't looking good for the next few
 weeks for me so someone else should take over if it is important for
 4.16.

 Tyler
>>>
>>> This is also on my todo list, but it sits behind fixing one last
>>> libseccomp bug and getting a new release out.  I made some good
>>> progress on the libseccomp bug right before the holiday, but I think
>>> there is still a days worth of work left before it is ready to be
>>> merged.  I'm also traveling for the next week so I doubt I'll have any
>>> serious time to devote to the kernel patch(es).
>>>
>>> I can't remember what Tyler's last thought was on the logic, but I
>>> imagine I'll just wait until I see some patches to review/merge, or I
>>> can go back in the thread if I happen to have time before anyone else.
>>>
>>> Also, to set expectations, since we are currently at -rc6, this is
>>> likely going to need to wait until 4.17 at the earliest as I generally
>>> don't like merging new functionality in the last week or two before
>>> the merge window.
>>>
>>> Also (part two), we should add a test case to the audit-testsuite for
>>> any new knobs that affect the SECCOMP records.
>>
>>
>>
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: filename not audited for openat() on F28

2018-04-24 Thread Richard Guy Briggs 
On 2018-04-24 12:40, Richard Guy Briggs wrote:
> On 2018-04-20 15:20, Jiri Jaburek wrote:
> > (Please CC me on replies.)
> > 
> > Hello,
> > I'm trying to run the audit-test suite on Fedora 28 and am running into
> > it expecting a name= field in the SYSCALL entry.
> > 
> > augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
> > pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
> > egid=0 sgid=0 fsgid=0 exit=-13
> > subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
> > name=tmp.owfFtgPOjx/new
> 
> Can you distill this down to one rule and one action that trigger this
> so I can do some testing on other versions?  I see no "key=" label on
> the rule (explicit or implicit) that triggered it.

I was able to recreate it with:
# auditctl -a always,exit -F arch=b64 -S all -F perm=rwxa -F 
dir=/tmp/test/ -F key=test_create

and then an unprivileged write to /tmp/test/create with:
$ echo test > /tmp/test/create

> This is a bit of a surprise, but I have been doing some work in that
> area and I'd like to see if any of it might have caused it.  I'm
> doubtful, but would like to track it down to see if it was intentional
> or not.

4.8.15-200.fc24.x86_64 new behaviour
4.7.2-201.fc24.x86_64 new behaviour

4.6.7-300.fc24.x86_64 old behaviour
4.6.7-200.fc23.x86_64 old behaviour

Newer ones were consistent with the two new above and older ones were
consistent with the older two above.

$ git log --oneline stable/linux-4.6.y..stable/linux-4.7.y 
stable: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

I see nothing obvious in the 11 patches that metion audit.

Even more narrow, I find:

$ git log --oneline v4.6.7..v4.7.2
on the stable tree tags gives me 7 patches from the audit tree that
don't look obvious (except fc64005 which is some of viro's magic).

I did a quick search for the fedora kernel git tree and didn't find it
except for this:
https://src.fedoraproject.org/cgit/kernel.git
which appears to have vanished.  This may be it:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
but I don't find the tags above.

As Steve mentions, this was reporting a failure to create a file, so it
never existed.  The attempted filename is mentioned in the AVC record.
This doesn't help us with rule-generated events.

That same range of kernel versions has 43 changed to fs/namei.c which
will take a little longer to examine...

> > Fedora 28:
> > 
> > 
> > time->Fri Apr 20 15:04:59 2018
> > type=PROCTITLE msg=audit(1524229499.918:366591):
> > proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
> > type=PATH msg=audit(1524229499.918:366591): item=0
> > name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
> > rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
> > cap_fp= cap_fi= cap_fe=0 cap_fver=0
> > type=CWD msg=audit(1524229499.918:366591):
> > cwd="/usr/local/eal4_testing/audit-test/syscalls"
> > type=SYSCALL msg=audit(1524229499.918:366591): arch=c03e syscall=257
> > success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
> > ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
> > exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> > subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> > type=AVC msg=audit(1524229499.918:366591): avc:  denied  { create } for
> > pid=5276 comm="do_openat" name="new"
> > scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
> > tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
> > 
> > 
> > RHEL-7.5:
> > 
> > 
> > time->Fri Apr 20 15:06:59 2018
> > type=PROCTITLE msg=audit(1524229619.726:56605):
> > proctitle=72756E636F6E007374615F753A6C7370705F746573745F723A6C7370705F746573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E6174002F746D7000746D702E30674C74574A336977622F6E657700637265617465007374615F753A6F626A6563745F723A757365725F746D705F743A53
> > type=PATH msg=audit(1524229619.726:56605): item=1
> > name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=
> > cap_fi= cap_fe=0 cap_fver=0
> > type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
> > inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
> > obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
> > cap_fp= cap_fi= cap_fe=0 cap_fver=0
> > type=CWD msg=audit(1524229619.726:56605):
> > cwd="/usr/local/eal4_testing/audit-test/syscalls"
> > type=SYSCALL msg=audit(1524229619.726:56605): arch=c03e syscall=257
> > success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
> > pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) ses=1595 comm="do_openat"
> > exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> >

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

2018-04-24 Thread Paul Moore 
On Mon, Apr 23, 2018 at 10:02 PM, Richard Guy Briggs  wrote:
> On 2018-04-23 19:15, Paul Moore wrote:
>> On Sat, Apr 21, 2018 at 10:34 AM, Richard Guy Briggs  wrote:
>> > On 2018-04-18 19:47, Paul Moore wrote:
>> >> On Fri, Mar 16, 2018 at 5:00 AM, 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 "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(-)

...

>> >> >  /* audit_rule_data supports filter rules with both integer and string
>> >> >   * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
>> >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
>> >> > index 4e0a4ac..29c8482 100644
>> >> > --- a/kernel/auditsc.c
>> >> > +++ b/kernel/auditsc.c
>> >> > @@ -2073,6 +2073,90 @@ int audit_set_loginuid(kuid_t loginuid)
>> >> > return rc;
>> >> >  }
>> >> >
>> >> > +static int audit_set_containerid_perm(struct task_struct *task, u64 
>> >> > containerid)
>> >> > +{
>> >> > +   struct task_struct *parent;
>> >> > +   u64 pcontainerid, ccontainerid;
>> >> > +
>> >> > +   /* Don't allow to set our own containerid */
>> >> > +   if (current == task)
>> >> > +   return -EPERM;
>> >>
>> >> Why not?  Is there some obvious security concern that I missing?
>> >
>> > We then lose the distinction in the AUDIT_CONTAINER record between the
>> > initiating PID and the target PID.  This was outlined in the proposal.
>>
>> I just went back and reread the v3 proposal and I still don't see a
>> good explanation of this.  Why is this bad?  What's the security
>> concern?
>
> I don't remember, specifically.  Maybe this has been addressed by the
> check for children/threads or identical parent container ID.  So, I'm
> reluctantly willing to remove that check for now.

Okay.  For the record, if someone can explain to me why this
restriction saves us from some terrible situation I'm all for leaving
it.  I'm just opposed to restrictions without solid reasoning behind
them.

>> > Having said that, I'm still not sure we have protected sufficiently from
>> > a child turning around and setting it's parent's as yet unset or
>> > inherited audit container ID.
>>
>> Yes, I believe we only want to let a task set the audit container for
>> it's children (or itself/threads if we decide to allow that, see
>> above).  There *has* to be a function to check to see if a task if a
>> child of a given task ... right? ... although this is likely to be a
>> pointer traversal and locking nightmare ... hmmm.
>
> Isn't that just (struct task_struct)parent == (struct
> task_struct)child->parent (or ->real_parent)?
>
> And now that I say that, it is covered by the following patch's child
> check, so as long as we keep that, we should be fine.

I was thinking of checking not just current's immediate children, but
any of it's descendants as I believe that is what we want to limit,
yes?  I just worry that it isn't really practical to perform that
check.

>> >> I ask because I suppose it might be possible for some container
>> >> runtime to do a fork, setup some of the environment and them exec the
>> >> container (before you answer the obvious "namespaces!" please remember
>> >> we're not trying to

Re: filename not audited for openat() on F28

2018-04-24 Thread Richard Guy Briggs 
On 2018-04-20 15:20, Jiri Jaburek wrote:
> (Please CC me on replies.)
> 
> Hello,
> I'm trying to run the audit-test suite on Fedora 28 and am running into
> it expecting a name= field in the SYSCALL entry.
> 
> augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
> pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
> egid=0 sgid=0 fsgid=0 exit=-13
> subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
> name=tmp.owfFtgPOjx/new

Can you distill this down to one rule and one action that trigger this
so I can do some testing on other versions?  I see no "key=" label on
the rule (explicit or implicit) that triggered it.

This is a bit of a surprise, but I have been doing some work in that
area and I'd like to see if any of it might have caused it.  I'm
doubtful, but would like to track it down to see if it was intentional
or not.

> Fedora 28:
> 
> 
> time->Fri Apr 20 15:04:59 2018
> type=PROCTITLE msg=audit(1524229499.918:366591):
> proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
> type=PATH msg=audit(1524229499.918:366591): item=0
> name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
> rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0
> type=CWD msg=audit(1524229499.918:366591):
> cwd="/usr/local/eal4_testing/audit-test/syscalls"
> type=SYSCALL msg=audit(1524229499.918:366591): arch=c03e syscall=257
> success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
> ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
> exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> type=AVC msg=audit(1524229499.918:366591): avc:  denied  { create } for
> pid=5276 comm="do_openat" name="new"
> scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
> tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
> 
> 
> RHEL-7.5:
> 
> 
> time->Fri Apr 20 15:06:59 2018
> type=PROCTITLE msg=audit(1524229619.726:56605):
> proctitle=72756E636F6E007374615F753A6C7370705F746573745F723A6C7370705F746573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E6174002F746D7000746D702E30674C74574A336977622F6E657700637265617465007374615F753A6F626A6563745F723A757365725F746D705F743A53
> type=PATH msg=audit(1524229619.726:56605): item=1
> name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=
> cap_fi= cap_fe=0 cap_fver=0
> type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
> inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
> obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
> cap_fp= cap_fi= cap_fe=0 cap_fver=0
> type=CWD msg=audit(1524229619.726:56605):
> cwd="/usr/local/eal4_testing/audit-test/syscalls"
> type=SYSCALL msg=audit(1524229619.726:56605): arch=c03e syscall=257
> success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
> pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=1595 comm="do_openat"
> exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> 
> 
> The key difference here is probably the absence of
> 
> type=PATH msg=audit(1524229619.726:56605): item=1
> name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=
> cap_fi= cap_fe=0 cap_fver=0
> 
> on Fedora 28, which augrok looks for.
> 
> Is this expected?
> 
> 
> 
> I'm seeing something similar with other syscalls like
> 
> creat("/tmp/tmp.9EsMgMuio7/new", 0700)
> 
> producing
> 
> 
> type=PROCTITLE msg=audit(04/20/2018 15:15:35.547:371576) :
> proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
> do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
> type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
> name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
> ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
> nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
> type=CWD msg=audit(04/20/2018 15:15:35.547:371576) :
> cwd=/usr/local/eal4_testing/audit-test/syscalls
> type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
> syscall=creat success=no exit=EACCES(Permission denied)
> a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
> auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
> sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
> exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc:  denied  {
> create } for  pid=6780 comm=do_creat name=new
>

Re: [PATCH v2] audit: allow not equal op for audit by executable

2018-04-24 Thread Paul Moore 
On Mon, Apr 9, 2018 at 4:00 AM, Ondrej Mosnacek  wrote:
> From: Ondrej Mosnáček 
>
> Current implementation of auditing by executable name only implements
> the 'equal' operator. This patch extends it to also support the 'not
> equal' operator.
>
> See: https://github.com/linux-audit/audit-kernel/issues/53
>
> Signed-off-by: Ondrej Mosnacek 
> ---
>  kernel/auditfilter.c | 2 +-
>  kernel/auditsc.c | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)

Merged into audit/next, thanks.

> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index d7a807e81451..a0c5a3ec6e60 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -426,7 +426,7 @@ static int audit_field_valid(struct audit_entry *entry, 
> struct audit_field *f)
> return -EINVAL;
> break;
> case AUDIT_EXE:
> -   if (f->op != Audit_equal)
> +   if (f->op != Audit_not_equal && f->op != Audit_equal)
> return -EINVAL;
> if (entry->rule.listnr != AUDIT_FILTER_EXIT)
> return -EINVAL;
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 4e0a4ac803db..479c031ec54c 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -471,6 +471,8 @@ static int audit_filter_rules(struct task_struct *tsk,
> break;
> case AUDIT_EXE:
> result = audit_exe_compare(tsk, rule->exe);
> +   if (f->op == Audit_not_equal)
> +   result = !result;
> break;
> case AUDIT_UID:
> result = audit_uid_comparator(cred->uid, f->op, 
> f->uid);
> --
> 2.14.3
>



-- 
paul moore
www.paul-moore.com

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

Re: Monitoring files

2018-04-24 Thread Richard Guy Briggs 
On 2018-04-23 23:41, F Rafi wrote:
> Adding a -i to the rules file should ignore any errors.

At risk of feature creep, it might be nice to have a flag to ignore
certain rules but not others, a way to tag individual rules with either
a must, or a different tag with "ignore if not present" for file rules.

> -Farhan
> 
> On Mon, Apr 23, 2018 at 9:19 PM, warron.french  
> wrote:
> > Hi, I have a requirement to monitor a ton of files, executables and confug
> > files.
> >
> > Anyway, not all of my systems have every file in the list; and when I add
> > the rules appropriate, either as a Watch (-w) rule or as an Action (-a)
> > rule, the rules stop loading when the find a rule that has a file that
> > doesn't exist *on that particular system*.
> >
> > This is the intended effect, yes?
> >
> > Thanks in advance,
> > --
> > Warron French

- 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