* Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
From: Paul Moore @ 2016-04-10 22:17 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andi Kleen, linux-kernel, linux-audit
In-Reply-To: <20160410024152.GG9407@two.firstfloor.org>
On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> What kernel version are you using? I believe we fixed that in Linux
>> 4.5 with the following:
>
> This is 4.6-rc2.
>>
>> commit 96368701e1c89057bbf39222e965161c68a85b4b
>> From: Paul Moore <pmoore@redhat.com>
>> Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
>>
>> audit: force seccomp event logging to honor the audit_enabled flag
>
> No you didn't fix it because audit_enabled is always enabled by systemd
> for user space auditing, see the original description of my patch.
[NOTE: adding the audit list to the CC line]
Sorry, I read your email too quickly; you are correct, that commit
fixed a different problem.
Let me think on this a bit more. Technically I don't see this as a
bug with the kernel, userspace is enabling audit and you are getting
audit messages as a result; from my opinion this is the expected
behavior. However, we've talked in the past about providing better
control over seccomp's auditing/logging and that work would allow you
to quiet all seccomp messages if you desired.
If you are interested, I started tracking this issue at the link below:
* https://github.com/linux-audit/audit-kernel/issues/13
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New field to auditd.conf file
From: Paul Moore @ 2016-04-07 18:42 UTC (permalink / raw)
To: Deepika Sundar; +Cc: linux-audit
In-Reply-To: <CAHj_pNfcDRfRw8jSa1hHLp+GxUedpCfSOcazWES2otu29zwqow@mail.gmail.com>
On Thu, Apr 7, 2016 at 12:47 AM, Deepika Sundar
<sundar.deepika18@gmail.com> wrote:
> In the same way, in the kernel side
> Can I able to add one new field to the audit log structure without breaking
> Compatibility? If so,
> 1.How can I add new field without breaking compatibility?
> or
> 2.Is there any reserve field in audit log structure so that I can make use
> of it?
You need to be more specific about what you are trying to do.
Speaking generally, unless you work to get your changed merged into
the upstream kernel and userspace tools we cannot guarantee present or
future compatibility.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New field to auditd.conf file
From: Deepika Sundar @ 2016-04-07 4:47 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1492101.S1y4DdPXGo@x2>
[-- Attachment #1.1: Type: text/plain, Size: 990 bytes --]
In the same way, in the kernel side
Can I able to add one new field to the audit log structure without breaking
Compatibility?If so,
1.How can I add new field without breaking compatibility?
or
2. Is there any reserve field in audit log structure so that I can make use
of it?
On Wed, Apr 6, 2016 at 5:47 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, April 06, 2016 05:25:36 PM Deepika Sundar wrote:
> > Ok.If i wanted to add the new field to experiment on the requirement,
> which
> > are the files(programs) that need changes or to be updated to take
> effect
> > on new field in auditd.conf?
>
> auditd-config.c
>
>
> > On Wed, Apr 6, 2016 at 5:20 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, April 06, 2016 05:06:08 PM Deepika Sundar wrote:
> > > > Can it be possible to add new field to auditd.conf file?
> > >
> > > That depends entirely on what functionality is being added and if its
> > > acceptable to people in general.
> > >
> > > -Steve
>
>
[-- Attachment #1.2: Type: text/html, Size: 1583 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] audit: we don't need to __set_current_state(TASK_RUNNING)
From: Paul Moore @ 2016-04-06 17:41 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160406165624.GH19769@madcap2.tricolour.ca>
On Wednesday, April 06, 2016 12:56:24 PM Richard Guy Briggs wrote:
> On 16/04/05, Paul Moore wrote:
> > From: Paul Moore <paul@paul-moore.com>
> >
> > Remove the calls to __set_current_state() to mark the task as running
> > and do some related cleanup in wait_for_auditd() to limit the amount
> > of work we do when we aren't going to reschedule the current task.
>
> Wow, the logic of this goes back to 9ad9ad38 (2005-06-22, AUDIT: Wait
> for backlog to clear when generating messages.)
Yeah, I didn't think much of it until Jiri submitted that last patch and
figured I should check how we were doing handling the rescheduling in the rest
of the code. I think it stayed the way it was for so long because technically
it wasn't hurting anything.
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
>
> These changes look good to me.
>
> > ---
> >
> > kernel/audit.c | 12 +++++-------
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 3a3e5de..f52fbef 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> >
> > @@ -430,7 +430,6 @@ restart:
> > attempts, audit_pid);
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > schedule();
> >
> > - __set_current_state(TASK_RUNNING);
> >
> > goto restart;
> >
> > }
> >
> > }
> >
> > @@ -1324,15 +1323,14 @@ static inline void audit_get_stamp(struct
> > audit_context *ctx,>
> > static long wait_for_auditd(long sleep_time)
> > {
> >
> > DECLARE_WAITQUEUE(wait, current);
> >
> > - set_current_state(TASK_UNINTERRUPTIBLE);
> > - add_wait_queue_exclusive(&audit_backlog_wait, &wait);
> >
> > if (audit_backlog_limit &&
> >
> > - skb_queue_len(&audit_skb_queue) > audit_backlog_limit)
> > + skb_queue_len(&audit_skb_queue) > audit_backlog_limit) {
> > + add_wait_queue_exclusive(&audit_backlog_wait, &wait);
> > + set_current_state(TASK_UNINTERRUPTIBLE);
> >
> > sleep_time = schedule_timeout(sleep_time);
> >
> > -
> > - __set_current_state(TASK_RUNNING);
> > - remove_wait_queue(&audit_backlog_wait, &wait);
> > + remove_wait_queue(&audit_backlog_wait, &wait);
> > + }
> >
> > return sleep_time;
> >
> > }
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems,
> Red Hat Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] audit: we don't need to __set_current_state(TASK_RUNNING)
From: Richard Guy Briggs @ 2016-04-06 16:56 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <145988111225.11221.4809537837118530054.stgit@localhost>
On 16/04/05, Paul Moore wrote:
> From: Paul Moore <paul@paul-moore.com>
>
> Remove the calls to __set_current_state() to mark the task as running
> and do some related cleanup in wait_for_auditd() to limit the amount
> of work we do when we aren't going to reschedule the current task.
Wow, the logic of this goes back to 9ad9ad38 (2005-06-22, AUDIT: Wait
for backlog to clear when generating messages.)
> Signed-off-by: Paul Moore <paul@paul-moore.com>
These changes look good to me.
> ---
> kernel/audit.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 3a3e5de..f52fbef 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -430,7 +430,6 @@ restart:
> attempts, audit_pid);
> set_current_state(TASK_INTERRUPTIBLE);
> schedule();
> - __set_current_state(TASK_RUNNING);
> goto restart;
> }
> }
> @@ -1324,15 +1323,14 @@ static inline void audit_get_stamp(struct audit_context *ctx,
> static long wait_for_auditd(long sleep_time)
> {
> DECLARE_WAITQUEUE(wait, current);
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - add_wait_queue_exclusive(&audit_backlog_wait, &wait);
>
> if (audit_backlog_limit &&
> - skb_queue_len(&audit_skb_queue) > audit_backlog_limit)
> + skb_queue_len(&audit_skb_queue) > audit_backlog_limit) {
> + add_wait_queue_exclusive(&audit_backlog_wait, &wait);
> + set_current_state(TASK_UNINTERRUPTIBLE);
> sleep_time = schedule_timeout(sleep_time);
> -
> - __set_current_state(TASK_RUNNING);
> - remove_wait_queue(&audit_backlog_wait, &wait);
> + remove_wait_queue(&audit_backlog_wait, &wait);
> + }
>
> return sleep_time;
> }
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: syscall - "comm" field truncated
From: Richard Guy Briggs @ 2016-04-06 15:21 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhQ_W9ke8Vej1CZWNTnkK2VXY2-CjjvAaE5YEb364MkbaA@mail.gmail.com>
On 16/04/06, Paul Moore wrote:
> On Wed, Apr 6, 2016 at 9:53 AM, Lev Stipakov <lstipakov@gmail.com> wrote:
> > Hello,
> >
> > Sometimes audit of "execve" syscall generates events with truncated "comm"
> > values, for example:
> >
> > type=SYSCALL msg=audit(1459950426.152:1097081): arch=c000003e syscall=59
> > success=yes exit=0 a0=35bae3e a1=1bc0cf0 a2=2b09280 a3=58c items=2 ppid=2183
> > pid=26566 auid=4294967295 uid=1001 gid=1001 euid=1001
> > suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none)
> > ses=4294967295 comm="gnome-calculato" exe="/usr/bin/gnome-calculator"
> >
> > Why "comm" is "gnome-calculato" and not "/usr/bin/gnome-calculator" ?
>
> This is due to a limitation in how the kernel records the comm field
> and isn't likely to change.
It is set in the kernel, in file include/linux/sched.h,
struct task_struct, member comm, with length TASK_COMM_LEN which is 16.
Changing it would break all kinds of stuff, so as was mentioned,
PROCTITLE is used to get the kind of information you seek.
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: syscall - "comm" field truncated
From: Steve Grubb @ 2016-04-06 14:37 UTC (permalink / raw)
To: linux-audit, Lev Stipakov
In-Reply-To: <CAHC9VhQ_W9ke8Vej1CZWNTnkK2VXY2-CjjvAaE5YEb364MkbaA@mail.gmail.com>
On Wednesday, April 06, 2016 10:05:35 AM Paul Moore wrote:
> On Wed, Apr 6, 2016 at 9:53 AM, Lev Stipakov <lstipakov@gmail.com> wrote:
> > Hello,
> >
> > Sometimes audit of "execve" syscall generates events with truncated "comm"
> > values, for example:
> >
> > type=SYSCALL msg=audit(1459950426.152:1097081): arch=c000003e syscall=59
> > success=yes exit=0 a0=35bae3e a1=1bc0cf0 a2=2b09280 a3=58c items=2
> > ppid=2183 pid=26566 auid=4294967295 uid=1001 gid=1001 euid=1001
> > suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none)
> > ses=4294967295 comm="gnome-calculato" exe="/usr/bin/gnome-calculator"
> >
> > Why "comm" is "gnome-calculato" and not "/usr/bin/gnome-calculator" ?
>
> This is due to a limitation in how the kernel records the comm field
> and isn't likely to change.
And just to add some history to this, there was a big discussion about this
back when the AUDIT_PROCTITLE record was added to syscall events. (Jan 2014)
Mainline kernel wouldn't allow it to be increased. So, we wound up with the
PROCTITLE record which supplies the missing information and more.
-Steve
^ permalink raw reply
* Re: syscall - "comm" field truncated
From: Paul Moore @ 2016-04-06 14:05 UTC (permalink / raw)
To: Lev Stipakov; +Cc: linux-audit
In-Reply-To: <ne34de$drk$1@ger.gmane.org>
On Wed, Apr 6, 2016 at 9:53 AM, Lev Stipakov <lstipakov@gmail.com> wrote:
> Hello,
>
> Sometimes audit of "execve" syscall generates events with truncated "comm"
> values, for example:
>
> type=SYSCALL msg=audit(1459950426.152:1097081): arch=c000003e syscall=59
> success=yes exit=0 a0=35bae3e a1=1bc0cf0 a2=2b09280 a3=58c items=2 ppid=2183
> pid=26566 auid=4294967295 uid=1001 gid=1001 euid=1001
> suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none)
> ses=4294967295 comm="gnome-calculato" exe="/usr/bin/gnome-calculator"
>
> Why "comm" is "gnome-calculato" and not "/usr/bin/gnome-calculator" ?
This is due to a limitation in how the kernel records the comm field
and isn't likely to change.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* syscall - "comm" field truncated
From: Lev Stipakov @ 2016-04-06 13:53 UTC (permalink / raw)
To: linux-audit
Hello,
Sometimes audit of "execve" syscall generates events with truncated
"comm" values, for example:
type=SYSCALL msg=audit(1459950426.152:1097081): arch=c000003e syscall=59
success=yes exit=0 a0=35bae3e a1=1bc0cf0 a2=2b09280 a3=58c items=2
ppid=2183 pid=26566 auid=4294967295 uid=1001 gid=1001 euid=1001
suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none)
ses=4294967295 comm="gnome-calculato" exe="/usr/bin/gnome-calculator"
Why "comm" is "gnome-calculato" and not "/usr/bin/gnome-calculator" ?
Same for Firefiox:
type=SYSCALL msg=audit(1459950158.667:1092149): arch=c000003e syscall=59
success=yes exit=0 a0=7f913ed1ddf0 a1=7f9144819be0 a2=7f9173f14400
a3=786f666572696600 items=2 ppid=26165 pid=26247 auid=4294967295
uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001
fsgid=1001 tty=(none) ses=4294967295 comm="plugin-containe"
exe="/usr/lib/firefox/plugin-container"
comm is "plugin-containe" and not "plugin-container".
Audit version is 2.4.2-1ubuntu1.
-Lev
^ permalink raw reply
* Re: New field to auditd.conf file
From: Steve Grubb @ 2016-04-06 12:17 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHj_pNf9Ktnz2ZThwWK+YTHKWZYiY0RE1UzmU6inv8A0jNz_ug@mail.gmail.com>
On Wednesday, April 06, 2016 05:25:36 PM Deepika Sundar wrote:
> Ok.If i wanted to add the new field to experiment on the requirement, which
> are the files(programs) that need changes or to be updated to take effect
> on new field in auditd.conf?
auditd-config.c
> On Wed, Apr 6, 2016 at 5:20 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, April 06, 2016 05:06:08 PM Deepika Sundar wrote:
> > > Can it be possible to add new field to auditd.conf file?
> >
> > That depends entirely on what functionality is being added and if its
> > acceptable to people in general.
> >
> > -Steve
^ permalink raw reply
* Re: New field to auditd.conf file
From: Deepika Sundar @ 2016-04-06 11:55 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <2428041.aDPSTkrCU6@x2>
[-- Attachment #1.1: Type: text/plain, Size: 501 bytes --]
Ok.If i wanted to add the new field to experiment on the requirement, which
are the files(programs) that need changes or to be updated to take effect
on new field in auditd.conf?
On Wed, Apr 6, 2016 at 5:20 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, April 06, 2016 05:06:08 PM Deepika Sundar wrote:
> > Can it be possible to add new field to auditd.conf file?
>
> That depends entirely on what functionality is being added and if its
> acceptable to people in general.
>
> -Steve
>
[-- Attachment #1.2: Type: text/html, Size: 884 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New field to auditd.conf file
From: Steve Grubb @ 2016-04-06 11:50 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHj_pNdUgE22Mz0JLWiW01pkK6rtahXd1V06ATyvedQMjUWcNQ@mail.gmail.com>
On Wednesday, April 06, 2016 05:06:08 PM Deepika Sundar wrote:
> Can it be possible to add new field to auditd.conf file?
That depends entirely on what functionality is being added and if its
acceptable to people in general.
-Steve
^ permalink raw reply
* New field to auditd.conf file
From: Deepika Sundar @ 2016-04-06 11:36 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 67 bytes --]
Can it be possible to add new field to auditd.conf file?
-Deepika
[-- Attachment #1.2: Type: text/html, Size: 134 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Auditing User Additions - Critical Oversight?
From: Steve Grubb @ 2016-04-05 22:57 UTC (permalink / raw)
To: linux-audit; +Cc: Blackwell, Joseph M
In-Reply-To: <198b4e40890b4a1dbd4a83c039317d4a@XCH15-09-12.nw.nos.boeing.com>
Hello,
On Tuesday, April 05, 2016 09:48:01 PM Blackwell, Joseph M wrote:
> I am working on scripting a report that can be run to filter and display the
> audits on a weekly basis, and I am having issues pulling specific events
> that indicate when users are added through the User Manager GUI (GNOME
> 2.28.2). I have nispom.rules file running on kernel "2.6.32-220.el6.x86_64
> (RHEL 6.2)". The following are the only events that show up in the
> audit.log for this activity.
>
> type=USER_ACCT msg=audit(04/05/2016 14:21:42.854:36615) : user pid=15667
> uid=root auid=root ses=2
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> msg='op=PAM:accounting acct=root exe=/usr/sbin/userhelper hostname=? addr=?
> terminal=? res=success' ----
> type=USER_START msg=audit(04/05/2016 14:21:42.870:36616) : user pid=15667
> uid=root auid=root ses=2
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> msg='op=PAM:session_open acct=root exe=/usr/sbin/userhelper hostname=?
> addr=? terminal=? res=success'
>
> These events are followed by other SYSCALL events showing root writing to
> shadow, gshadow, and passwd, but no indication of the actual account that
> was created/modified. Unless I am not configured correctly, these seems
> like a critical oversight. Perhaps I am missing something?
This is well known at least to anyone working in this area.
> I know that we can gather other events, such as when the useradd command is
> used, but there are many admins that prefer to use the GUI. I suppose I
> could copy the passwd file on a weekly basis and perform a diff, but it
> seems to me that this type of information should be baked in already,
> especially in cases where we are using indexers such as splunk.
No one has ever certified a Linux desktop under OSPP. Common Criteria is the
big hammer that causes things to get done. After doing a brief survey of GUI
user managers, none seem to use pam which means password policy is also
probably not enforced.
-Steve
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Burn Alting @ 2016-04-05 22:39 UTC (permalink / raw)
To: Boyce, Kevin P (AS)
Cc: Greg KH, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <ffef94ad8d7a4770a4a192488a5be1c3-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
On Tue, 2016-04-05 at 14:42 +0000, Boyce, Kevin P (AS) wrote:
> Burn,
>
> > Hence my final comment below about well known devices and the desire monitor open/openat/etc for write system calls on 'deemed removable media' ie one day we could set up
> auditctl -F arch=b64 -a always,exit -S open -F a1&3 -F dev=removable -k RMopen
>
> And even when you try to figure this out for a CD it is next to impossible to know what is written. If I remember correctly when running strace on wodim you don't ever see the write() calls on the filenames. And instead, what if someone creates an iso image and burns that to a DVD. You really have no way of knowing what is on that disc. When the burn process is complete, the disc usually gets ejected, so the audit subsystem would never even get a chance to evaluate the filesystem that was written to optical media.
Two issues here.
1. If you need to know what has been transferred to removable media,
then use appropriate DLP (data loss prevention) capability that, not
only provides management on who/what can be involved in transfers, but
can also keep shadow copies of data transferred.
2. If no DLP tools are available, then we need to make use of audit but
we do not rely on a single event in isolation. Reviewing events both
before and after a removable media event, along with events from other
services (web servers, applications) allows one to build a 'balance of
probabilities' picture of what has occurred. (The balance of
probabilities is improved with more information of value and it's
integrity).
Apologies for going off topic on theses lists, but I am hoping this
background to our requirements will aid in any further discussion
regarding solutions people such as Wade are investigating. If there is a
desire to continue, it's probably best we move such discussions to audit
specific lists or dedicated forums and return when required with
kernel/usb specific issues.
Regards
Burn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 22:18 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-audit, Oliver Neukum, Wade Mealing, linux-usb, linux-kernel,
bjorn
In-Reply-To: <2074584.b2h7oKljRp@x2>
On Tue, Apr 05, 2016 at 03:38:34PM -0400, Steve Grubb wrote:
> On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote:
> > On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote:
> > > Consider the following scenario. Currently we have device drivers
> > > that emit text via a printk request which is eventually picked up by
> > > syslog like implementation (not the audit subsystem).
> >
> > We also have UEVENTs. The crucial question is why udevd feeding
> > back events to the audit subsystem is inferior to the kernel
> > itself generating audit events.
>
> If this was going to be done in user space, then we are talking about auditd
> growing the ability to monitor another netlink socket for events. The question
> that decides if this is feasible is whether or not UEVENTS are protected from
> loss if several occur in a short time before auditd can get around to reading
> them.
udevd should queue up your events that you subscribe to just fine. Test
it out if you want to, it should be pretty easy.
> The other issue that I'm curious about is if adding hardware can fail.
Sure it can, plug in a "broken" USB device and watch it not enumerate
properly :)
> Do the events coming out by UEVENTS have any sense of pass or fail? Or
> are they all implicitly successful?
They only happen when a device is successfully added to the kernel.
> And then we get to the issue of whether or not UEVENTS can be filtered. If so,
> then we will also need to add auditing around the configuration of the filters
> to see if anything is impacting the audit trail.
You can filter in userspace, that's what udevd provides for you today.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Wade Mealing @ 2016-04-05 22:17 UTC (permalink / raw)
To: Alan Stern
Cc: Bjørn Mork, Oliver Neukum, linux-audit, linux-kernel,
linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1604051035580.2233-100000@iolanthe.rowland.org>
O
>
> If you want a place in the kernel to add audit records for all devices
> added to or removed from the system, the right place to do it is in
> drivers/base/core.c, the device_add() and device_del() routines.
> That's where the ADD and REMOVE uevents are created.
>
> Alan Stern
I agree with you on this. The device_add and device_del functions
use notification chains
similar to how the USB subsystem can notify subscribers that new
devices have been added.
This was my initial implementation, USB already uses notification
chains for its device add/remove.
Thanks,
Wade Mealing.
^ permalink raw reply
* Auditing User Additions - Critical Oversight?
From: Blackwell, Joseph M @ 2016-04-05 21:48 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1598 bytes --]
Steve / et all,
I am working on scripting a report that can be run to filter and display the audits on a weekly basis, and I am having issues pulling specific events that indicate when users are added through the User Manager GUI (GNOME 2.28.2). I have nispom.rules file running on kernel "2.6.32-220.el6.x86_64 (RHEL 6.2)". The following are the only events that show up in the audit.log for this activity.
type=USER_ACCT msg=audit(04/05/2016 14:21:42.854:36615) : user pid=15667 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=root exe=/usr/sbin/userhelper hostname=? addr=? terminal=? res=success'
----
type=USER_START msg=audit(04/05/2016 14:21:42.870:36616) : user pid=15667 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct=root exe=/usr/sbin/userhelper hostname=? addr=? terminal=? res=success'
These events are followed by other SYSCALL events showing root writing to shadow, gshadow, and passwd, but no indication of the actual account that was created/modified. Unless I am not configured correctly, these seems like a critical oversight. Perhaps I am missing something?
I know that we can gather other events, such as when the useradd command is used, but there are many admins that prefer to use the GUI. I suppose I could copy the passwd file on a weekly basis and perform a diff, but it seems to me that this type of information should be baked in already, especially in cases where we are using indexers such as splunk.
-Joe Blackwell
[-- Attachment #1.2: Type: text/html, Size: 3852 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Steve Grubb @ 2016-04-05 19:38 UTC (permalink / raw)
To: linux-audit-H+wXaHxf7aLQT0dZR+AlfA
Cc: Oliver Neukum, Wade Mealing, linux-usb,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, bjorn-yOkvZcmFvRU
In-Reply-To: <1459875768.2892.1.camel-IBi9RG/b67k@public.gmane.org>
On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote:
> On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote:
> > Consider the following scenario. Currently we have device drivers
> > that emit text via a printk request which is eventually picked up by
> > syslog like implementation (not the audit subsystem).
>
> We also have UEVENTs. The crucial question is why udevd feeding
> back events to the audit subsystem is inferior to the kernel
> itself generating audit events.
If this was going to be done in user space, then we are talking about auditd
growing the ability to monitor another netlink socket for events. The question
that decides if this is feasible is whether or not UEVENTS are protected from
loss if several occur in a short time before auditd can get around to reading
them.
The other issue that I'm curious about is if adding hardware can fail. Do the
events coming out by UEVENTS have any sense of pass or fail? Or are they all
implicitly successful?
And then we get to the issue of whether or not UEVENTS can be filtered. If so,
then we will also need to add auditing around the configuration of the filters
to see if anything is impacting the audit trail.
-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] audit: we don't need to __set_current_state(TASK_RUNNING)
From: Paul Moore @ 2016-04-05 18:31 UTC (permalink / raw)
To: linux-audit
From: Paul Moore <paul@paul-moore.com>
Remove the calls to __set_current_state() to mark the task as running
and do some related cleanup in wait_for_auditd() to limit the amount
of work we do when we aren't going to reschedule the current task.
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
kernel/audit.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 3a3e5de..f52fbef 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -430,7 +430,6 @@ restart:
attempts, audit_pid);
set_current_state(TASK_INTERRUPTIBLE);
schedule();
- __set_current_state(TASK_RUNNING);
goto restart;
}
}
@@ -1324,15 +1323,14 @@ static inline void audit_get_stamp(struct audit_context *ctx,
static long wait_for_auditd(long sleep_time)
{
DECLARE_WAITQUEUE(wait, current);
- set_current_state(TASK_UNINTERRUPTIBLE);
- add_wait_queue_exclusive(&audit_backlog_wait, &wait);
if (audit_backlog_limit &&
- skb_queue_len(&audit_skb_queue) > audit_backlog_limit)
+ skb_queue_len(&audit_skb_queue) > audit_backlog_limit) {
+ add_wait_queue_exclusive(&audit_backlog_wait, &wait);
+ set_current_state(TASK_UNINTERRUPTIBLE);
sleep_time = schedule_timeout(sleep_time);
-
- __set_current_state(TASK_RUNNING);
- remove_wait_queue(&audit_backlog_wait, &wait);
+ remove_wait_queue(&audit_backlog_wait, &wait);
+ }
return sleep_time;
}
^ permalink raw reply related
* Re: [RFC] Create an audit record of USB specific details
From: Oliver Neukum @ 2016-04-05 17:02 UTC (permalink / raw)
To: Wade Mealing; +Cc: bjorn, linux-audit, linux-kernel, linux-usb
In-Reply-To: <CALJHwhR5FQaa6v=ZPyLRZ8L+OrucXqEiwe6QE43HybM2keErYg@mail.gmail.com>
On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote:
> Consider the following scenario. Currently we have device drivers
> that emit text via a printk request which is eventually picked up by
> syslog like implementation (not the audit subsystem).
We also have UEVENTs. The crucial question is why udevd feeding
back events to the audit subsystem is inferior to the kernel
itself generating audit events.
Regards
Oliver
^ permalink raw reply
* Re: EXT :Re: [RFC] Create an audit record of USB specific details
From: Greg KH @ 2016-04-05 15:35 UTC (permalink / raw)
To: Boyce, Kevin P (AS)
Cc: Wade Mealing, Bjørn Mork, Oliver Neukum,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <6bdd24ee68e64e4e91fa160940d357ed-cZmdoFAsBjDgAiKnVY1dJgQSgKfZeEaX@public.gmane.org>
On Tue, Apr 05, 2016 at 01:52:40PM +0000, Boyce, Kevin P (AS) wrote:
> Greg,
>
> > There is no "/proc/usb/" :)
>
> Sorry, maybe /sys/bus/usb/devices was what I was looking for...
>
> > The kernel calls mknod itself on devtmpfs, userspace doesn't do that anymore (hasn't for a long time). Do you get those audit events today?
>
> I'm not auditing those events myself. Just proposing ideas that might
> produce the sort of information Wade was looking for.
Ok, but watch out, lots of USB devices don't have a device node, they
get accessed directly by userspace applications, using the kernel as a
"raw" pass-through.
It's not an easy problem, good luck all!
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Paul Moore @ 2016-04-05 14:50 UTC (permalink / raw)
To: Greg KH
Cc: linux-audit-H+wXaHxf7aLQT0dZR+AlfA, wmealing,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160405033905.GA14854-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Apr 4, 2016 at 11:39 PM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote:
>> On April 4, 2016 6:17:23 PM Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>> > On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote:
>> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
>> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
>> > > > > From: Wade Mealing <wmealing-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> > > > >
>> > > > > Gday,
>> > > > >
>> > > > > I'm looking to create an audit trail for when devices are added or removed
>> > > > > from the system.
>> > > >
>> > > > Then please do it in userspace, as I suggested before, that way you
>> > > > catch all types of devices, not just USB ones.
>> > >
>> > > Audit has some odd requirements placed on it by some of its users. I think
>> > > most notable in this particular case is the need to take specific actions,
>> > > including panicking the system, when audit records can't be sent to userspace
>> > > and are "lost". Granted, it's an odd requirement, definitely not the
>> > > norm/default configuration, but supporting weird stuff like this has allowed
>> > > Linux to be used on some pretty interesting systems that wouldn't have been
>> > > possible otherwise. Looking quickly at some of the kobject/uvent code, it
>> > > doesn't appear that the uevent/netlink channel has this capability.
>> >
>> > Are you sure you can loose netlink messages? If you do, you know you
>> > lost them, so isn't that good enough?
>>
>> Last I checked netlink didn't have a provision for panicking the system, so
>> no :)
>
> Userspace can panic the system if it detects this, so why not just do
> that?
If the kernel isn't able to send a message to userspace, either due to
a netlink failure or some userspace failure, how is the kernel going
to reliably notify userspace to panic the system?
>> > > It also just noticed that it looks like userspace can send fake uevent
>> > > messages;
>> >
>> > That's how your machine boots properly :)
>>
>> Yes, it looks like that is how the initial devices are handled, right?
>> Allowing something like that is probably okay for a variety of reasons, but
>> I expect users would want to restrict access beyond this single trusted
>> process. The good news is that I think you should be able to do that with a
>> combination of DAC and MAC.
>
> Again, please step back. What exactly are you trying to do here? What
> is the requirement?
As I mentioned earlier, this bit about restricting access to uevents
was largely me thinking out loud and had to do with protecting the
integrity of the audit log from invalid uevent records. It isn't
important to the larger discussion and I believe I've sorted it in my
head anyway.
Regardless, I think Wade and Burn have done a pretty good job
explaining the larger picture of what they are trying to do, I guess
my question to you is what don't you understand about their
explanations?
>> > > I haven't looked at it closely enough yet, but that may be a concern
>> > > for users which restrict/subdivide root using a LSM ... although it is
>> > > possible that the LSM policy could help here. I'm thinking aloud a bit right
>> > > now, but for SELinux the netlink controls aren't very granular and sysfs can
>> > > be tricky so I can't say for certain about blocking fake events from userspace
>> > > using LSMs/SELinux.
>> >
>> > uevents are not tied into LSMs from what I can tell, so I don't
>> > understand wht you are talking about here, sorry.
>>
>> Perhaps I'm mistaken, but uevents are sent to userspace via netlink which
>> does have LSM controls. There also appears to be a file I/O mechanism via
>> sysfs which also has LSM controls.
>
> And do any of them look at uevents through these mechanisms?
>
> I doubt they care...
Not presently, but if they are tasked with preserving the integrity of
the audit events then they would care. However, as I typed above,
this isn't something worth worrying about right now and is likely just
a distraction.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: EXT :Re: [RFC] Create an audit record of USB specific details
From: Boyce, Kevin P (AS) @ 2016-04-05 14:42 UTC (permalink / raw)
To: burn-VQrJuM5UdZBN0TnZuCh8vA@public.gmane.org
Cc: Greg KH, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <1459867036.7998.112.camel-krJecHFEUit3UMzaYwuTPmD2FQJk+8+b@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 933 bytes --]
Burn,
> Hence my final comment below about well known devices and the desire monitor open/openat/etc for write system calls on 'deemed removable media' ie one day we could set up
auditctl -F arch=b64 -a always,exit -S open -F a1&3 -F dev=removable -k RMopen
And even when you try to figure this out for a CD it is next to impossible to know what is written. If I remember correctly when running strace on wodim you don't ever see the write() calls on the filenames. And instead, what if someone creates an iso image and burns that to a DVD. You really have no way of knowing what is on that disc. When the burn process is complete, the disc usually gets ejected, so the audit subsystem would never even get a chance to evaluate the filesystem that was written to optical media.
Kevin
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br šê+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹\x1e®w¥¢¸?™¨èÚ&¢)ߢ^[f
^ permalink raw reply
* Re: [RFC] Create an audit record of USB specific details
From: Alan Stern @ 2016-04-05 14:40 UTC (permalink / raw)
To: Wade Mealing
Cc: Bjørn Mork, Oliver Neukum, linux-audit, linux-kernel,
linux-usb
In-Reply-To: <CALJHwhR5FQaa6v=ZPyLRZ8L+OrucXqEiwe6QE43HybM2keErYg@mail.gmail.com>
On Tue, 5 Apr 2016, Wade Mealing wrote:
> I'm reframing my use case as follows to try and better explain the
> situation I am trying to track.
>
> It might seem that I am duplicating existing functionality, rather I
> am trying to augment functionality that seems to be
> unavailable.Replication of existing functionality is not my intention.
>
> Consider the following scenario. Currently we have device drivers
> that emit text via a printk request which is eventually picked up by
> syslog like implementation (not the audit subsystem).
>
> The goal of these message is to let a system administrator see in the
> audit logs, that a device has been plugged in and the basic details
> about this. Having this only in userspace means that (and Greg
> alludes to this ) that this will be for human eyes only and not be
> machine usable in the kernels. Without it being in kernel, it can't
> be extended for manipulation by auditctl at some point in the future.
>
> Specifically I am trying to create a well formed audit trail when
> devices are added or removed from the system by the userspace audit
> tools. The implementation at the moment does not do any filtering,
> but rather creates the raw audit events.
>
> In some ways this is similar to a decorated class in say java. In
> this case the class is unaware it is being decorated yet we can
> monitor what is happening in that class without polluting the class
> code with messy log or trace information.
>
> I don't see either kernel or user-space applications create add or
> remove events in the audit subsystem. I understand that some events
> are placed into uevents (To be intercepted by udevd), while this also
> exports the same information it is not in the audit subsystem in
> kernel.
>
> > I think the generic layer implementation is already there. The proposed
> > USB specific solution adds nothing, as pointed out by Greg the last time
> > this was discussed.
>
> I agree it would be ideal to use existing userspace or kernelspace
> facilities for auditing and not duplicating efforts, it seems that the
> specific case I am trying to track isn't covered. Maybe I missed it
> be can you indicate where device add/remove audit (not log messages)
> are being generated/implemented in the kernel or userspace for the
> scenario I described?
If you want a place in the kernel to add audit records for all devices
added to or removed from the system, the right place to do it is in
drivers/base/core.c, the device_add() and device_del() routines.
That's where the ADD and REMOVE uevents are created.
Alan Stern
^ 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