3:30 p.m.
Hello,
This topic has already been discussed on the SE Linux mail list. Because the
attached patch affects the audit code, I want to put it out here for
discussion as well. I started with a patch to put the program name into avc
messages and Stephen Smalley changed the patch to put the processing in
audit_log_exit.
There is a minor problem in the SE Linux avc messages that makes it hard to
interpret what has failed. For example, if you have a shell script that tries
to read a file that's in a different context, you get a message with
exe=/bin/sh. This causes trouble tracking down the rogue script.
The attached patch against 2.6.11 changes the output of an AVC denial message
so that it looks like this:
type=KERNEL msg=audit(1112293183.500:1591315): item=0 name=/usr/X11R6/bin/id
inode=573518 dev=03:02 mode=040755 uid=0 gid=0 rdev=00:00
type=KERNEL msg=audit(1112293183.500:1591315): syscall=195 exit=-13 a0=9ef71e8
a1=bfe1e850 a2=b6cff4 a3=9ef71e8 items=1 pid=3583 loginuid=525 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm=named exe=/bin/bash
type=KERNEL msg=audit(1112293183.500:1591315): avc: denied { search } for
name=bin dev=hda2 ino=573518 scontext=root:system_r:named_t
tcontext=system_u:object_r:bin_t tclass=dir
To get this, I deleted named, replaced it with a shell script that tries
to cat /etc/shadow. As you can see, it now says comm=named. You also get
the syscall information which could help policy writers correct problems
with less guessing. All around, its a plus for SE Linux.
How does this affect auditing? The audit record now has 2 new fields.
I put the following rules into the audit system:
-a entry,always -S execve
-a entry,always -S open
And within seconds got this:
type=KERNEL msg=audit(1112294058.648:2278762): syscall=5 exit=-2 a0=961f198
a1=18800 a2=2086b9 a3=18800 items=1 pid=3336 loginuid=525 uid=525 gid=525
euid=525 suid=525 fsuid=525 egid=525 sgid=525 fsgid=525 comm=gam_server
exe=/usr/libexec/gam_server
type=KERNEL msg=audit(1112294059.206:2279059): item=0 name=/dev/hdd inode=1357
dev=00:0d mode=060600 uid=525 gid=6 rdev=16:40
type=KERNEL msg=audit(1112294059.206:2279059): syscall=5 exit=4 a0=890b2f0
a1=8880 a2=0 a3=8880 items=1 pid=2744 loginuid=-1 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 comm=hald exe=/usr/sbin/hald
You now see what the exe's path is and what the program calls itself. This can
help interpret the audit messages since now you know that pid 2744 was the
hal daemon. So, I think this will be a big plus for auditing, too.
What do you guys think?
-Steve Grubb
5:39 a.m.
On Thu, 2005-03-31 at 16:30 -0500, Steve Grubb wrote:
@@ -556,39 +555,6 @@ void avc_audit(u32 ssid, u32 tsid,
audit_log_format(ab, "avc: %s ", denied ? "denied" :
"granted");
avc_dump_av(ab, tclass,audited);
audit_log_format(ab, " for ");
- if (a && a->tsk)
- tsk = a->tsk;
- if (tsk && tsk->pid) {
- struct mm_struct *mm;
- struct vm_area_struct *vma;
- audit_log_format(ab, " pid=%d", tsk->pid);
...
What replaces this information for the normal callers of avc_audit()?
--
dwmw2
7:18 a.m.
On Fri, 2005-04-01 at 12:39 +0100, David Woodhouse wrote:
On Thu, 2005-03-31 at 16:30 -0500, Steve Grubb wrote:
> @@ -556,39 +555,6 @@ void avc_audit(u32 ssid, u32 tsid,
> audit_log_format(ab, "avc: %s ", denied ? "denied" :
> "granted");
> avc_dump_av(ab, tclass,audited);
> audit_log_format(ab, " for ");
> - if (a && a->tsk)
> - tsk = a->tsk;
> - if (tsk && tsk->pid) {
> - struct mm_struct *mm;
> - struct vm_area_struct *vma;
> - audit_log_format(ab, " pid=%d", tsk->pid);
...
What replaces this information for the normal callers of avc_audit()?
Whenever avc_audit() generates a log message via audit_log*, the
auditable flag is enabled, so audit_log_exit() will be called upon
syscall exit and the exe= and comm= information will then be provided at
that time, and can be correlated with the avc message using the
timestamp and serial number. That will mean that people will need to
start enabling syscall auditing when using SELinux if they want to
retain the same set of information, but that is preferable to
duplicating the information in both avc_audit and audit_log_exit IMHO.
Note that avc_audit still generates the security context information, so
it still has everything needed to map a denial back to policy rules.
Note that the change also has side benefits for SELinux:
1) By determining the executable path (exe=) upon syscall exit rather
than within avc_audit, we can collect it more reliably. Note that the
current avc_audit code has to do an down_read_trylock on the mmap sem
because some callers of avc_audit may already have write locked it (e.g.
from mmap/mprotect hooks); audit_log_exit doesn't have this problem.
2) By moving all of the task-related audit generation to audit_log_exit,
we ensure that we don't include this information incorrectly for avc
denials that aren't in process context. At present, you can end up with
avc denials with bogus pid and exe information that has no relationship
to the actual denial because the denial occurred in non-process context
(e.g. for network permission checks, for sigio delivery). This often
confuses users.
I think we should also look into migrating some of the avc_audit
processing for object information to audit_log_exit (via the auxiliary
item list), but this will need to be done carefully based on whether
avc_audit can perform blocking allocation for the permission checks in
question and naturally not for any of the avc_audit processing of
permission checks that are not in process context.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7:36 a.m.
On Fri, 2005-04-01 at 08:18 -0500, Stephen Smalley wrote:
Whenever avc_audit() generates a log message via audit_log*, the
auditable flag is enabled, so audit_log_exit() will be called upon
syscall exit and the exe= and comm= information will then be provided at
that time, and can be correlated with the avc message using the
timestamp and serial number.
Setting the auditable flag is only going to cause audit_log_exit() to be
called on syscall exit _if_ audit_syscall_exit() is actually called.
That's often in the slow path of the syscall return, and triggered only
if something like TIF_SYSCALL_AUDIT is set in the thread_info flags.
--
dwmw2
7:35 a.m.
On Fri, 2005-04-01 at 14:36 +0100, David Woodhouse wrote:
Setting the auditable flag is only going to cause audit_log_exit() to
be
called on syscall exit _if_ audit_syscall_exit() is actually called.
That's often in the slow path of the syscall return, and triggered only
if something like TIF_SYSCALL_AUDIT is set in the thread_info flags.
Sorry, do you have an example of where this would be a problem?
Also, the only truly required information in avc_audit is the relevant
security contexts, security class, and permission(s); everything else is
just supplemental data to help track down the causes of policy denials.
I always expected that the audit framework would ultimately take over
handling of such supplemental data for SELinux, leaving it to only deal
with the MAC-specific information.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
8:34 a.m.
On Fri, 2005-04-01 at 14:36 +0100, David Woodhouse wrote:
Setting the auditable flag is only going to cause audit_log_exit() to
be
called on syscall exit _if_ audit_syscall_exit() is actually called.
That's often in the slow path of the syscall return, and triggered only
if something like TIF_SYSCALL_AUDIT is set in the thread_info flags.
Ok, if you think that this is a real concern, and given that syscall
auditing is presently disabled by default (requires explicit audit=1
kernel boot parameter or auditctl -e 1 to enable), possibly we should
drop the patch to avc_audit for now while still adding it to
audit_log_exit. However, eventually I'd like to revisit the issue.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
8:51 a.m.
On Friday 01 April 2005 09:34, Stephen Smalley wrote:
Ok, if you think that this is a real concern, and given that syscall
auditing is presently disabled by default (requires explicit audit=1
kernel boot parameter or auditctl -e 1 to enable),
Yes, this was a concern since it possibly changed the behavior of deployed
systems (RHEL4, FC3).
possibly we should drop the patch to avc_audit for now while still
adding it
to audit_log_exit.
If we go this route, I'd like to push my original patch to get comm and
syscall information in the avc messages. Dan has been wanting an improvement
in that area for quite a while.
-Steve
8:50 a.m.
On Fri, 2005-04-01 at 09:51 -0500, Steve Grubb wrote:
If we go this route, I'd like to push my original patch to get
comm and
syscall information in the avc messages. Dan has been wanting an improvement
in that area for quite a while.
IMHO, that's different - it is one thing to say that we won't remove any
information from the existing avc messages even if we duplicate it in
the syscall auditing for compatibility; it is another thing to add new
information to the avc messages that is better suited to the syscall
auditing. If Dan or others want new information, it is reasonable to
tell them to enable syscall auditing (after adding that information to
it). Telling people that they have to enable syscall auditing and
correlate multiple audit messages to retain old information is more
problematic.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
1:25 p.m.
On Friday 01 April 2005 09:50, Stephen Smalley wrote:
If Dan or others want new information, it is reasonable to
tell them to enable syscall auditing (after adding that information to
it). Telling people that they have to enable syscall auditing and
correlate multiple audit messages to retain old information is more
problematic.
I think we're OK with this. Where does that leave the patch?
-Steve Grubb
1:24 p.m.
On Fri, 2005-04-01 at 14:25 -0500, Steve Grubb wrote:
I think we're OK with this. Where does that leave the patch?
It just means that we keep the diff for auditsc.c as is, and drop the
diff for avc.c, i.e. we add comm and exe logging to the syscall auditing
but leave exe logging unmodified in the avc. Which I think is what
David Woodhouse did already for his kernel since he wasn't sure about
the avc change.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
1:51 p.m.
On Fri, 2005-04-01 at 14:24 -0500, Stephen Smalley wrote:
It just means that we keep the diff for auditsc.c as is, and drop
the
diff for avc.c, i.e. we add comm and exe logging to the syscall auditing
but leave exe logging unmodified in the avc. Which I think is what
David Woodhouse did already for his kernel since he wasn't sure about
the avc change.
It is. Since it's now purely an audit patch, should I put it into the BK
tree?
--
dwmw2
2:07 p.m.
On Fri, 2005-04-01 at 20:51 +0100, David Woodhouse wrote:
On Fri, 2005-04-01 at 14:24 -0500, Stephen Smalley wrote:
> It just means that we keep the diff for auditsc.c as is, and drop the
> diff for avc.c, i.e. we add comm and exe logging to the syscall auditing
> but leave exe logging unmodified in the avc. Which I think is what
> David Woodhouse did already for his kernel since he wasn't sure about
> the avc change.
It is. Since it's now purely an audit patch, should I put it into the BK
tree?
IMHO, yes.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7:42 a.m.
On Thu, 2005-03-31 at 16:30 -0500, Steve Grubb wrote:
Hello,
This topic has already been discussed on the SE Linux mail list. Because the
attached patch affects the audit code, I want to put it out here for
discussion as well. I started with a patch to put the program name into avc
messages and Stephen Smalley changed the patch to put the processing in
audit_log_exit.
BTW, I think we need to run the comm through audit_log_untrustedstring
or similar, and likewise for the path generated for the exe. Right?
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7:56 a.m.
On Friday 01 April 2005 08:42, Stephen Smalley wrote:
BTW, I think we need to run the comm through
audit_log_untrustedstring
or similar, and likewise for the path generated for the exe. Right?
Yes we do. I needed a kernel that has those functions before I could make that
adjustment.
-Steve Grubb
8:32 a.m.
On Fri, 2005-04-01 at 08:56 -0500, Steve Grubb wrote:
On Friday 01 April 2005 08:42, Stephen Smalley wrote:
> BTW, I think we need to run the comm through audit_log_untrustedstring
> or similar, and likewise for the path generated for the exe. Right?
Yes we do. I needed a kernel that has those functions before I could make that
adjustment.
It is already in the -mm patchset, e.g. 2.6.12-rc1-mm4.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7213
days inactive
7214
days old
linux-audit@lists.linux-audit.osci.io
16 comments
3 participants
participants (3)
-
David Woodhouse -
Stephen Smalley -
Steve Grubb