* Re: auditd not triggering ANOM_ROOT_TRANS record
From: William Roberts @ 2016-10-25 13:09 UTC (permalink / raw)
To: teroz; +Cc: linux-audit
In-Reply-To: <CANhT1Hh=J4aA2bm=2YMXVk5_zp9DNcwXx=SPdOTJj=yrEqnjag@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]
On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
>
> I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
>
I would imagine that if it's hijacking an already root or setuid binary,
you won't see anything. As far as that record goes, I have no idea, I'll
let an auditing expert answer that question.
>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 991 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* auditd not triggering ANOM_ROOT_TRANS record
From: teroz @ 2016-10-25 12:09 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 278 bytes --]
I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
[-- Attachment #1.2: Type: text/html, Size: 368 bytes --]
[-- Attachment #2: audit.log.excerpt --]
[-- Type: application/octet-stream, Size: 2386 bytes --]
type=USER_ACCT msg=audit(1477392049.316:187): pid=934 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="teroz" exe="/usr/lib/syste
type=CRED_DISP msg=audit(1477391860.052:309): pid=1086 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success'
type=AVC msg=audit(1477391878.107:310): avc: denied { write } for pid=1221 comm="passwd" path="/proc/1215/mem" dev="proc" ino=25986 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=file permissive=0
type=SYSCALL msg=audit(1477391878.107:310): arch=c000003e syscall=59 per=400000 success=yes exit=0 a0=563229803c50 a1=563229803140 a2=563229802540 a3=563229803140 items=1 ppid=1215 pid=1221 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
type=BPRM_FCAPS msg=audit(1477391878.107:310): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000003fffffffff new_pi=0000000000000000 new_pe=0000003fffffffff
type=EXECVE msg=audit(1477391878.107:310): argc=1 a0="/usr/bin/passwd"
type=CWD msg=audit(1477391878.107:310): cwd="/home/teroz"
type=PATH msg=audit(1477391878.107:310): item=0 name="/usr/bin/passwd" inode=275481 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:passwd_exec_t:s0 nametype=NORMAL
type=PROCTITLE msg=audit(1477391878.107:310): proctitle="/usr/bin/passwd"
type=AVC msg=audit(1477391878.108:311): avc: denied { read } for pid=1221 comm="bash" name=".bashrc" dev="dm-0" ino=8726369 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1477391878.108:311): arch=c000003e syscall=2 success=no exit=-13 a0=561de422cb40 a1=0 a2=9 a3=561de422ce60 items=1 ppid=1215 pid=1221 auid=1000 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V3 0/3] Add support for session ID user filtering
From: Paul Moore @ 2016-10-21 17:03 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: Paul Moore, linux-audit, linux-kernel
In-Reply-To: <20161021064658.GR23701@madcap2.tricolour.ca>
On Fri, Oct 21, 2016 at 2:46 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-10-20 15:27, Paul Moore wrote:
>> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote:
>> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
>> > RFE Session ID User Filter
>> >
>> > https://github.com/linux-audit/audit-kernel/issues/4
>> > RFE: add a session ID filter to the kernel's user filter
>> >
>> > See also the set of userspace suport patches:
>> > Add support for sessionid user filters, sessionid_set and loginuid_set
>> > https://www.redhat.com/archives/linux-audit/2016-August/msg00005.html
>> > (userspace update expected to be posted 2016-08-18)
>> > and the test case:
>> > https://github.com/rgbriggs/audit-testsuite/tree/ghak4-test-for-sessionID-u
>> > ser-filter
>> >
>> > This third patch is expected to have a merge conflict with:
>> > "audit: add exclude filter extension to feature bitmap"
>> > posted on 2016-08-18.
>> >
>> > Richard Guy Briggs (3):
>> > audit: add support for session ID user filter
>> > audit: add AUDIT_SESSIONID_SET support
>> > audit: add sessionid filter extension to feature bitmap
>> >
>> > include/linux/audit.h | 10 ++++++++++
>> > include/uapi/linux/audit.h | 6 +++++-
>> > kernel/auditfilter.c | 5 +++++
>> > kernel/auditsc.c | 6 ++++++
>> > 4 files changed, 26 insertions(+), 1 deletions(-)
>>
>> In light of our current decision to drop the session ID "set" filter, I'm
>> taking another look at these patches and Richard's comment to simply drop
>> patch 2/3 and apply 1/3 and 3/3.
>>
>> Richard, as I mentioned earlier, perhaps not clearly enough, I think we should
>> put a check in audit_set_loginuid() to skip the (int)-1 value from appearing
>> in session_id during normal operation. In other words, roll/reset the value
>> in session_id one value early so we don't run into problems with the (int)-1
>> unset sentinel value.
>
> I noted your comment earlier and I agree skipping the sentinel is
> required, but if we are rolling this counter, we have bigger issues
> unless there is a way to determine if a sessionID value is still in use
> by at least one task.
The session ID reuse problem is independent of the rollover problem;
the session ID value is going to roll at some point, regardless of if
we skip one value or not. I guess if there is any comfort in the
value rolling, it is only bumped on a new interactive user session and
given that systemd is now taking to killing all user processes on
logout (no more nohup'ing things) it is unlikely that this will be an
issue on a modern Linux system (it would appear that most everyone is
moving to systemd, for better or worse). For those truly paranoid
admins, they don't have to filter on it - problem solved - for
everyone else, it can be a useful tool.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V3 0/3] Add support for session ID user filtering
From: Richard Guy Briggs @ 2016-10-21 6:46 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel, sgrubb, eparis
In-Reply-To: <1817842.78IB8nV8t8@sifl>
On 2016-10-20 15:27, Paul Moore wrote:
> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote:
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
> > RFE Session ID User Filter
> >
> > https://github.com/linux-audit/audit-kernel/issues/4
> > RFE: add a session ID filter to the kernel's user filter
> >
> > See also the set of userspace suport patches:
> > Add support for sessionid user filters, sessionid_set and loginuid_set
> > https://www.redhat.com/archives/linux-audit/2016-August/msg00005.html
> > (userspace update expected to be posted 2016-08-18)
> > and the test case:
> > https://github.com/rgbriggs/audit-testsuite/tree/ghak4-test-for-sessionID-u
> > ser-filter
> >
> > This third patch is expected to have a merge conflict with:
> > "audit: add exclude filter extension to feature bitmap"
> > posted on 2016-08-18.
> >
> > Richard Guy Briggs (3):
> > audit: add support for session ID user filter
> > audit: add AUDIT_SESSIONID_SET support
> > audit: add sessionid filter extension to feature bitmap
> >
> > include/linux/audit.h | 10 ++++++++++
> > include/uapi/linux/audit.h | 6 +++++-
> > kernel/auditfilter.c | 5 +++++
> > kernel/auditsc.c | 6 ++++++
> > 4 files changed, 26 insertions(+), 1 deletions(-)
>
> In light of our current decision to drop the session ID "set" filter, I'm
> taking another look at these patches and Richard's comment to simply drop
> patch 2/3 and apply 1/3 and 3/3.
>
> Richard, as I mentioned earlier, perhaps not clearly enough, I think we should
> put a check in audit_set_loginuid() to skip the (int)-1 value from appearing
> in session_id during normal operation. In other words, roll/reset the value
> in session_id one value early so we don't run into problems with the (int)-1
> unset sentinel value.
I noted your comment earlier and I agree skipping the sentinel is
required, but if we are rolling this counter, we have bigger issues
unless there is a way to determine if a sessionID value is still in use
by at least one task.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH V3 0/3] Add support for session ID user filtering
From: Paul Moore @ 2016-10-20 19:27 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel, sgrubb, eparis
In-Reply-To: <cover.1471541331.git.rgb@redhat.com>
On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote:
> https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
> RFE Session ID User Filter
>
> https://github.com/linux-audit/audit-kernel/issues/4
> RFE: add a session ID filter to the kernel's user filter
>
> See also the set of userspace suport patches:
> Add support for sessionid user filters, sessionid_set and loginuid_set
> https://www.redhat.com/archives/linux-audit/2016-August/msg00005.html
> (userspace update expected to be posted 2016-08-18)
> and the test case:
> https://github.com/rgbriggs/audit-testsuite/tree/ghak4-test-for-sessionID-u
> ser-filter
>
> This third patch is expected to have a merge conflict with:
> "audit: add exclude filter extension to feature bitmap"
> posted on 2016-08-18.
>
> Richard Guy Briggs (3):
> audit: add support for session ID user filter
> audit: add AUDIT_SESSIONID_SET support
> audit: add sessionid filter extension to feature bitmap
>
> include/linux/audit.h | 10 ++++++++++
> include/uapi/linux/audit.h | 6 +++++-
> kernel/auditfilter.c | 5 +++++
> kernel/auditsc.c | 6 ++++++
> 4 files changed, 26 insertions(+), 1 deletions(-)
In light of our current decision to drop the session ID "set" filter, I'm
taking another look at these patches and Richard's comment to simply drop
patch 2/3 and apply 1/3 and 3/3.
Richard, as I mentioned earlier, perhaps not clearly enough, I think we should
put a check in audit_set_loginuid() to skip the (int)-1 value from appearing
in session_id during normal operation. In other words, roll/reset the value
in session_id one value early so we don't run into problems with the (int)-1
unset sentinel value.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: EXTERNAL: Re: Audit watches on NFS mounts
From: Steve Grubb @ 2016-10-20 16:22 UTC (permalink / raw)
To: Vaughn, Chad M; +Cc: linux-audit@redhat.com
In-Reply-To: <E594E682CA7FE04DAD586665D2142F742D6C614F@HDXDSP53.us.lmco.com>
On Thursday, October 20, 2016 4:10:43 PM EDT Vaughn, Chad M wrote:
> Thanks for the quick response. That makes sense.
>
> One other thing, on Redhat 6.4 if the watch dir does not exist, ie automount
> NFS, then auditd will bomb out and not even start.
I have my doubts on this. What I would expect to happen is that the rules
being loaded by auditctl will get an error from the kernel and that is
displayed. If you do not have a rule to ignore errors then it will stop the
rule loading. Auditd itself should be up and running. The init script starts
auditd and then after its running, loads rules by auditctl.
> On Redhat 6.8, it seems to not care and start up anyway (better). Kernel or
> Auditd?
That was also a kernel change. Auditd is pretty much like a specialized
syslog.
-Steve
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, October 20, 2016 10:38 AM
> To: Vaughn, Chad M (US) <chad.m.vaughn@lmco.com>
> Cc: linux-audit@redhat.com
> Subject: EXTERNAL: Re: Audit watches on NFS mounts
>
> On Thursday, October 20, 2016 2:42:07 PM EDT Vaughn, Chad M wrote:
> > I noticed a weird behavior. I NFS mount /usr/local on my Redhat machines.
> >
> > If I put a watch for a directory in that NFS mount:
> >
> > -w /usr/local/mywatchdir/ -p rwxa -F exit!=-ENODATA -F success!=1 -k
> > watch
> >
> > On Redhat 6.4, I don't see audit events when trying to remove or
> > change files in that dir. On Redhat 6.8, I do see the audit events
> > when trying to remove or changes files in that dir.
> >
> > Any ideas of possible features added to auditd between those releases?
> > I would like to be able to speak to it for security audits.
>
> Auditd is just the collector. The events are generated by the kernel. So, it
> would be a kernel change that may have allowed that. I don't know what was
> changed or which version did it. I do know that in the past it was not
> possible to audit nfs or fuse based file systems.
>
> -Steve
^ permalink raw reply
* RE: EXTERNAL: Re: Audit watches on NFS mounts
From: Vaughn, Chad M @ 2016-10-20 16:10 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <14342226.LmfWeh2Ifs@x2>
Thanks for the quick response. That makes sense.
One other thing, on Redhat 6.4 if the watch dir does not exist, ie automount NFS, then auditd will bomb out and not even start.
On Redhat 6.8, it seems to not care and start up anyway (better). Kernel or Auditd?
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, October 20, 2016 10:38 AM
To: Vaughn, Chad M (US) <chad.m.vaughn@lmco.com>
Cc: linux-audit@redhat.com
Subject: EXTERNAL: Re: Audit watches on NFS mounts
On Thursday, October 20, 2016 2:42:07 PM EDT Vaughn, Chad M wrote:
> I noticed a weird behavior. I NFS mount /usr/local on my Redhat machines.
>
> If I put a watch for a directory in that NFS mount:
>
> -w /usr/local/mywatchdir/ -p rwxa -F exit!=-ENODATA -F success!=1 -k
> watch
>
> On Redhat 6.4, I don't see audit events when trying to remove or
> change files in that dir. On Redhat 6.8, I do see the audit events
> when trying to remove or changes files in that dir.
>
> Any ideas of possible features added to auditd between those releases?
> I would like to be able to speak to it for security audits.
Auditd is just the collector. The events are generated by the kernel. So, it would be a kernel change that may have allowed that. I don't know what was changed or which version did it. I do know that in the past it was not possible to audit nfs or fuse based file systems.
-Steve
^ permalink raw reply
* Re: Audit watches on NFS mounts
From: Steve Grubb @ 2016-10-20 15:37 UTC (permalink / raw)
To: Vaughn, Chad M; +Cc: linux-audit@redhat.com
In-Reply-To: <E594E682CA7FE04DAD586665D2142F742D6C60FA@HDXDSP53.us.lmco.com>
On Thursday, October 20, 2016 2:42:07 PM EDT Vaughn, Chad M wrote:
> I noticed a weird behavior. I NFS mount /usr/local on my Redhat machines.
>
> If I put a watch for a directory in that NFS mount:
>
> -w /usr/local/mywatchdir/ -p rwxa -F exit!=-ENODATA -F success!=1 -k watch
>
> On Redhat 6.4, I don't see audit events when trying to remove or change
> files in that dir. On Redhat 6.8, I do see the audit events when trying to
> remove or changes files in that dir.
>
> Any ideas of possible features added to auditd between those releases? I
> would like to be able to speak to it for security audits.
Auditd is just the collector. The events are generated by the kernel. So, it
would be a kernel change that may have allowed that. I don't know what was
changed or which version did it. I do know that in the past it was not
possible to audit nfs or fuse based file systems.
-Steve
^ permalink raw reply
* Audit watches on NFS mounts
From: Vaughn, Chad M @ 2016-10-20 14:42 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
I noticed a weird behavior. I NFS mount /usr/local on my Redhat machines.
If I put a watch for a directory in that NFS mount:
-w /usr/local/mywatchdir/ -p rwxa -F exit!=-ENODATA -F success!=1 -k watch
On Redhat 6.4, I don't see audit events when trying to remove or change files in that dir.
On Redhat 6.8, I do see the audit events when trying to remove or changes files in that dir.
Any ideas of possible features added to auditd between those releases? I would like to be able to speak to it for security audits.
^ permalink raw reply
* Re: Use logrotate for audit logs?
From: Ryan Sawhill @ 2016-10-20 14:15 UTC (permalink / raw)
To: leam hall; +Cc: linux-audit
In-Reply-To: <CACv9p5qHt9PtjzoBxZ6_WP26rnQ4Q7yxFY=wsVx607z4qnddAg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]
On Thu, Oct 20, 2016 at 7:32 AM, leam hall <leamhall@gmail.com> wrote:
> In this case, Steve talks about the system being taken down due to audit
> logs filling up the volumes. When that's not the best idea for a server, it
> looks like logrotate is a better choice.
No. You misunderstand.
auditd CAN be configured to take the system down when there's no more space
for audit logs; it does not do this by default. (See auditd.conf's various
*_action directives, e.g., disk_full_action.) There is IMHO very little
reason to switch to using logrotate. Please check out `man auditd.conf`.
[-- Attachment #1.2: Type: text/html, Size: 921 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Use logrotate for audit logs?
From: leam hall @ 2016-10-20 11:32 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1582503953.4711064.1476909977446.JavaMail.zimbra@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1100 bytes --]
On Wed, Oct 19, 2016 at 4:46 PM, Simon Sekidde <ssekidde@redhat.com> wrote:
> Hi Leam
>
> ----- Original Message -----
> > From: "leam hall" <leamhall@gmail.com>
> > To: linux-audit@redhat.com
> > Sent: Wednesday, October 19, 2016 3:26:23 PM
> > Subject: Use logrotate for audit logs?
> >
> > Is there any reason to not use logrotate for audit logs on RHEL 6? We'd
> like
> > to keep them fresh and compressed.
> >
>
> This was discussed a while back
>
> https://www.redhat.com/archives/linux-audit/2012-November/msg00008.html
>
> > Thanks!
> >
> > Leam
> >
> > --
> > Mind on a Mission
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
> --
> Simon Sekidde * Red Hat, Inc. * Tyson's Corner, VA
> gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E
>
>
Simon, thanks!
In this case, Steve talks about the system being taken down due to audit
logs filling up the volumes. When that's not the best idea for a server, it
looks like logrotate is a better choice.
Leam
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 2434 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [userspace PATCH v2 0/3] Add support for sessionid user filters, sessionid_set
From: Steve Grubb @ 2016-10-19 21:46 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <1471546054-4536-1-git-send-email-rgb@redhat.com>
On Thursday, August 18, 2016 2:47:31 PM EDT Richard Guy Briggs wrote:
> Add support for sessionid, sessionid_set (first two patches) and
> feature bitmap detection of the kernel feature (third patch) in user
> filters. This is to implement issue "ghak4":
> https://github.com/linux-audit/audit-kernel/issues/4
>
> https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
>
> This patchset should be added after loginuid_set and exclude filter
> extension to avoid merge conflicts.
Applied after removing sessionid_set code
-Steve
^ permalink raw reply
* Re: Use logrotate for audit logs?
From: Simon Sekidde @ 2016-10-19 20:46 UTC (permalink / raw)
To: leam hall; +Cc: linux-audit
In-Reply-To: <CACv9p5qtTOT7se+HFVfzvbgus3dmwGP=PGVm_qgHZqhMhw+GoA@mail.gmail.com>
Hi Leam
----- Original Message -----
> From: "leam hall" <leamhall@gmail.com>
> To: linux-audit@redhat.com
> Sent: Wednesday, October 19, 2016 3:26:23 PM
> Subject: Use logrotate for audit logs?
>
> Is there any reason to not use logrotate for audit logs on RHEL 6? We'd like
> to keep them fresh and compressed.
>
This was discussed a while back
https://www.redhat.com/archives/linux-audit/2012-November/msg00008.html
> Thanks!
>
> Leam
>
> --
> Mind on a Mission
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Simon Sekidde * Red Hat, Inc. * Tyson's Corner, VA
gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E
^ permalink raw reply
* Use logrotate for audit logs?
From: leam hall @ 2016-10-19 19:26 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 182 bytes --]
Is there any reason to not use logrotate for audit logs on RHEL 6? We'd
like to keep them fresh and compressed.
Thanks!
Leam
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 397 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Logging parameters
From: Steve Grubb @ 2016-10-18 15:15 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CACy5G63YQu85ZP-0p8WX0fU_cNea85OAC3=tkH3MPPE6tnXkmg@mail.gmail.com>
On Tuesday, October 18, 2016 4:59:58 PM EDT Nil . wrote:
> Hi, i would like to know if it is possible to log the parameters that a
> command get's passed on,
> i.e in the command ' ls -la', the logs only show comm="ls" and i would like
> to have the full comm="ls -la".
> is it possible anyhow using audit logs? do you know any other way to log
> those parameters?
These are captured in the PROCTITLE record of the event. If you do not have
that record attached to events, then you need a newer or patched kernel. So,
you should have it on a recent kernel.
-Steve
^ permalink raw reply
* Logging parameters
From: Nil . @ 2016-10-18 14:59 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 307 bytes --]
Hi, i would like to know if it is possible to log the parameters that a
command get's passed on,
i.e in the command ' ls -la', the logs only show comm="ls" and i would like
to have the full comm="ls -la".
is it possible anyhow using audit logs? do you know any other way to log
those parameters?
thank you
[-- Attachment #1.2: Type: text/html, Size: 427 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [userspace PATCH v2 2/3] Add sessionid_set option from kernel uapi macro AUDIT_SESSIONID_SET
From: Richard Guy Briggs @ 2016-10-18 12:36 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhQ9d=i06mT8dCOsd1wQdGD-LteCqDLUGPVbnPhv8Cq=gg@mail.gmail.com>
On 2016-10-13 08:32, Paul Moore wrote:
> On Wed, Oct 12, 2016 at 2:02 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, August 18, 2016 2:47:33 PM EDT Richard Guy Briggs wrote:
> >> Add sessionid_set field option from kernel uapi macro SESSIONID_SET to
> >> enable specifying that sessionID is set or not in user filters.
> >
> > Is there any compelling reason to support two differents fields that essentially
> > decide how to audit sessions? I think its a bit clunky to expect that people
> > write rules
> >
> > -a always,exit -S open -F path=/path/file -F sessionid>0
> >
> > but if you want to record daemons, then its not as simple as using -1 which is
> > what is in the logs and the intuitive answer. Instead you have to use a new
> > field.
> >
> > -a always,exit -S open -F path=/path/file -F sessionid_set=0
> >
> > But then you can also do the first rule as:
> >
> > -a always,exit -S open -F path=/path/file -F sessionid_set=1
> >
> > So, we have 2 ways of doing almost the same thing. I don't really like this.
>
> I originally thought the loginuid_set filter functionality was added
> to satisfy a request made by you for the audit userspace; I suggested
> to Richard that we do the same for the session ID since there were
> some definite similarities. However, having looked back at the
> original motivation for adding the loginuid_set functionality, I don't
> we will face the same problem with the session ID. If Richard can't
> think of any compelling reason to keep a dedicated sessionid_set
> filter, I think we can drop it.
>
> Further, while I understand why Eric B. needed to make the internal
> audit kernel changes to the loginuid code (and other audit UID/GID
> bits for that matter), I'm less convinced on the need to change the
> kernel/userspace filter API to add the loginuid_set capability.
> However, that was before my time, and it's done now, we can't yank it
> out at this point.
Well, Steve argues that -1 is more intuitive than "unset", which I
disagree unless you have always done that or you are a programmer. I'd
argue most of the users aren't programmers. And certainly that huge
number of 4 billion and something isn't something I'm going to remember
off the top of my head (and I'm a programmer) and the users certainly
aren't going to understand the significance of when making rules. Eric
isn't the first to reasonably propose not to use special values in-band
due to hoops that need to be jumped to work around complications that
can create (including needing to check for rolling the counter).
As far as Eric's patch set is concerned, he needed to make that change
only as a check that we weren't carelessly throwing around UIDs and GIDs
in the kernel without proper translation to the right user namespace,
but he didn't need to break the existing API to do that. That was a
bug. Now that cat was out of the bag, it was harder to stuff it back
in. I agreed with the fix at the time to add AUDIT_LOGINUID_SET due to
my aversion to in-band signalling, but the better solution would have
been to unbreak userspace and re-allow -1 and not complicate things
further with the internal representation of another field to represent
unset.
Given sessionID is a new filter field, I'd prefer the dedicated field to
indicate it is unset from the get-go to avoid the more complicated mess
we are now in with loginuid_set in deprecating loginuid==-1, but that
isn't the one obvious solution.
I suspect there are no users of AUDIT_LOGINUID_SET, so we could likely
rip it out and nobody would notice, and in that case, it would be
obvious to make sessionID behave the same way, in-banding -1 to indicate
unset.
All of which to say, I guess deprecating AUDIT_LOGINUID_SET is the best
way to go and not add loginuid_set in userspace tools and not implement
sessionid_set at all.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Richard Guy Briggs @ 2016-10-18 10:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20161018043526.GH32641@madcap2.tricolour.ca>
On 2016-10-18 00:35, Richard Guy Briggs wrote:
> On 2016-10-17 18:21, Steve Grubb wrote:
> > On Monday, October 17, 2016 5:19:59 PM EDT Paul Moore wrote:
> > > We haven't merged any of the session ID code into the kernel so
> > > changes are still possible. The logic for supporting loginuid_set
> > > (UID namespace issues) don't really apply to session IDs so I think we
> > > can drop the sessionid_set part of the API and just use the -1
> > > sentinel.
> >
> > OK, that's good to hear. I'll fix up and merge the sessionid patch - no need to
> > re-send the user space piece.
>
> userspace patch 2 gets dropped, paches 1 and 3 need rework to not block
> -1 and to remove sessionid_set respectively. kernel patch 2 gets
> dropped and patch 1 I think needs rework to allow -1.
Kernel patch 1 does not need rework because I properly put the positive
integer check for sessionID in the sessionID_set patch that adds that.
> The test patches also need rework as does the RFE page.
>
> > -Steve
>
> - RGB
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Richard Guy Briggs @ 2016-10-18 4:35 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1594202.aPB8anKs2i@x2>
On 2016-10-17 18:21, Steve Grubb wrote:
> On Monday, October 17, 2016 5:19:59 PM EDT Paul Moore wrote:
> > We haven't merged any of the session ID code into the kernel so
> > changes are still possible. The logic for supporting loginuid_set
> > (UID namespace issues) don't really apply to session IDs so I think we
> > can drop the sessionid_set part of the API and just use the -1
> > sentinel.
>
> OK, that's good to hear. I'll fix up and merge the sessionid patch - no need to
> re-send the user space piece.
userspace patch 2 gets dropped, paches 1 and 3 need rework to not block
-1 and to remove sessionid_set respectively. kernel patch 2 gets
dropped and patch 1 I think needs rework to allow -1.
The test patches also need rework as does the RFE page.
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-17 22:21 UTC (permalink / raw)
To: Paul Moore; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAGH-KgsMSbsD9j0Buyipzzbh1v-M36k8iQ1o+WkL8iiQwA66xQ@mail.gmail.com>
On Monday, October 17, 2016 5:19:59 PM EDT Paul Moore wrote:
> We haven't merged any of the session ID code into the kernel so
> changes are still possible. The logic for supporting loginuid_set
> (UID namespace issues) don't really apply to session IDs so I think we
> can drop the sessionid_set part of the API and just use the -1
> sentinel.
OK, that's good to hear. I'll fix up and merge the sessionid patch - no need to
re-send the user space piece.
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Paul Moore @ 2016-10-17 21:19 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161017154017.GF23701@madcap2.tricolour.ca>
On Mon, Oct 17, 2016 at 11:40 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-10-11 18:15, Paul Moore wrote:
>> Looking back through the git logs, it looks like it originally came
>> out of the user namespace work by Eric Biederman.
>
> That's exactly where it came from. Eric submitted the patch 780a7654 to
> fix the regression caused by e1760bd (userns: Convert the audit loginuid
> to be a kuid) and its set of 9 patches that were part of a 41-patch set.
> I notice Paul was Cc:-ed on that set...
I don't have the time to dig through my mail to see what all was
included in that patchset, but based on the git log that patch was
from April 2013 and I didn't become responsible for the audit code
until October 2014. I also don't see my Acked-by/Reviewed-by tag on
that commit so it is safe to say I was busy with other things at the
time. There are plenty of things you can blame me for, this ain't one
of 'em.
> I had to work around the work
> around when Steve reported the "f24=..." values.
>
> I can accept that Steve doesn't want to add more ways of doing the same
> thing, so I don't have an easy answer in terms of AUDIT_LOGINUID_SET
> being exposed in the UAPI.
>
> Since sessionid is a new field for filter specification (but not
> reporting and searching), I blocked sessionid==-1 in the api for setting
> filters. This unfortunately makes it a different way to specify it than
> loginuid when it is not set.
We are not going to change the loginuid related mechanisms at this
point; they aren't causing any breakage, and I don't want to break the
existing kernel/user API without a good reason.
We haven't merged any of the session ID code into the kernel so
changes are still possible. The logic for supporting loginuid_set
(UID namespace issues) don't really apply to session IDs so I think we
can drop the sessionid_set part of the API and just use the -1
sentinel. If you are all still looking to blame somebody, you can all
blame me for suggesting session ID to Richard.
Richard, if we use -1 as a magic number for the session ID, we should
make sure we roll the session ID value assigned to new sessions before
we hit -1 in audit_set_loginuid(...).
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-17 17:06 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161017165153.GG23701@madcap2.tricolour.ca>
On Monday, October 17, 2016 12:51:53 PM EDT Richard Guy Briggs wrote:
> On 2016-10-17 12:04, Steve Grubb wrote:
> > On Monday, October 17, 2016 11:40:17 AM EDT Richard Guy Briggs wrote:
> > > Since sessionid is a new field for filter specification (but not
> > > reporting and searching), I blocked sessionid==-1 in the api for setting
> > > filters. This unfortunately makes it a different way to specify it than
> > > loginuid when it is not set.
> >
> > Can we unblock that?
>
> Sure, then we would have two ways to express the same thing and ends up
> using in-band signalling which is what Eric was trying to avoid in the
> first place.
The plan would be to not use sessionid_set at all. Then we have one way to do
things. I doubt anyone is using either of the set functions. Just mark them
deprecated in the comments.
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Richard Guy Briggs @ 2016-10-17 16:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1658401.VrPGUNHXAh@x2>
On 2016-10-17 12:04, Steve Grubb wrote:
> On Monday, October 17, 2016 11:40:17 AM EDT Richard Guy Briggs wrote:
> > Since sessionid is a new field for filter specification (but not
> > reporting and searching), I blocked sessionid==-1 in the api for setting
> > filters. This unfortunately makes it a different way to specify it than
> > loginuid when it is not set.
>
> Can we unblock that?
Sure, then we would have two ways to express the same thing and ends up
using in-band signalling which is what Eric was trying to avoid in the
first place.
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-17 16:04 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161017154017.GF23701@madcap2.tricolour.ca>
On Monday, October 17, 2016 11:40:17 AM EDT Richard Guy Briggs wrote:
> Since sessionid is a new field for filter specification (but not
> reporting and searching), I blocked sessionid==-1 in the api for setting
> filters. This unfortunately makes it a different way to specify it than
> loginuid when it is not set.
Can we unblock that?
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Richard Guy Briggs @ 2016-10-17 15:40 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAGH-KgvMe6kn_ZOEid2YAUYt_852PuPEGht=ANJBUw0DuoGMWw@mail.gmail.com>
On 2016-10-11 18:15, Paul Moore wrote:
> On Tue, Oct 11, 2016 at 5:31 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, October 11, 2016 4:54:26 PM EDT Paul Moore wrote:
> >> On Tue, Oct 11, 2016 at 4:50 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> >> > On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote:
> >> >> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> >> >> > On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
> >> >> >> On 2016-10-11 12:40, Steve Grubb wrote:
> >> >> >> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> >> >> >> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com>
> >> >
> >> > wrote:
> >> >> >> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs
> >> >
> >> > wrote:
> >> >> >> > > >> loginuid_set support should have been added to userspace when
> >> >> >> > > >> it
> >> >> >> > > >> was
> >> >> >> > > >> added to the kernel around v3.10. Add it before we do similar
> >> >> >> > > >> for
> >> >> >> > > >> sessionID and sessionID_set.
> >> >> >> > > >
> >> >> >> > > > If this were accepted, how would this change writing rules? IOW,
> >> >> >> > > > can
> >> >> >> > > > you
> >> >> >> > > > give an example rule so we can see what this looks like?
> >> >> >> > >
> >> >> >> > > We have a RFE feature page which documents some rule examples:
> >> >> >> > >
> >> >> >> > > *
> >> >> >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-Us
> >> >> >> > > er-> >> > > Fil ter
> >> >> >> >
> >> >> >> > OK, thanks. This is helpful. So, what is the difference between
> >> >> >> > these
> >> >> >> > rules?
> >> >> >> >
> >> >> >> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
> >> >> >> >
> >> >> >> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
> >> >> >>
> >> >> >> The only difference is one flag in the kernel to indicate how it was
> >> >> >> invoked to be able to report when queried exactly the same way it was
> >> >> >> invoked, but there is no difference in the actual behaviour of the
> >> >> >> filter. This was added because of your report that "f24=0" was
> >> >> >> reported
> >> >> >> instead of loginuid_set=0 for backwards compatibility.
> >> >> >
> >> >> > OK. Generally its bad to have 2 ways to do the same thing. People use
> >> >> > SCAP
> >> >> > content to check system configurations. If there's two ways to do the
> >> >> > same
> >> >> > thing, then someone can accidentally choose the wrong way and fail
> >> >> > their
> >> >> > scan. We run into this in the past where we allowed -a exit,always and
> >> >> > -a
> >> >> > always,exit. All the rules had to be reworked to be consistent.
> >> >> > Therefore, I would recommend not using the loginuid_set option. We
> >> >> > still
> >> >> > get questions about -w /path/file -p wa vs -a always,exit -F
> >> >> > path=/path/file -F perm=wa. But that one is so deeply embedded that it
> >> >> > should not be fixed.
> >> >> >
> >> >> >> Going forward, the implementation of the sessionid_set field (which
> >> >> >> works similarly) will not allow an unset value of sessionid since
> >> >> >> these
> >> >> >> are a new addition that didn't need to accomodate backward
> >> >> >> compatibility.
> >> >> >
> >> >> > As long as we can trigger on sessionid=-1, then we are fine.
> >> >>
> >> >> Wait a minute ... what happened to the loginuid_set patches? Didn't
> >> >> those get merged to userspace?
> >> >
> >> > I'm reviewing this patch set for merging now that we are past all the 2.6
> >> > bug fixing.
> >>
> >> Ah, nevermind ... I confused loginuid and sessionid, sorry about the
> >> confusion.
> >>
> >> Anyway, I thought the desire for having a dedicated "is the loginuid
> >> value set?" filter came from userspace? If not, where did this
> >> requirement come from?
> >
> > I don't know where it came from. We have always used -1 for unset loginuid and
> > session id.
>
> Looking back through the git logs, it looks like it originally came
> out of the user namespace work by Eric Biederman.
That's exactly where it came from. Eric submitted the patch 780a7654 to
fix the regression caused by e1760bd (userns: Convert the audit loginuid
to be a kuid) and its set of 9 patches that were part of a 41-patch set.
I notice Paul was Cc:-ed on that set... I had to work around the work
around when Steve reported the "f24=..." values.
I can accept that Steve doesn't want to add more ways of doing the same
thing, so I don't have an easy answer in terms of AUDIT_LOGINUID_SET
being exposed in the UAPI.
Since sessionid is a new field for filter specification (but not
reporting and searching), I blocked sessionid==-1 in the api for setting
filters. This unfortunately makes it a different way to specify it than
loginuid when it is not set.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox