4:01 p.m.
The attached patch implements the full relabel audit event (Ie. an
audit event occurs when a full relabel occurs, ie. when /.autorelabel
exists at boot).
Note that although the code is correct, this patch doesn't actually
work due to kernel bugs[1].
It'll be in Fedora development as part of policycoreutils-1.30.10-3
onwards.
[1] see the thread on linux-audit if you want the details.
--
James Antill <jantill(a)redhat.com>
12:05 p.m.
On Thu, 2006-05-25 at 17:01 -0400, James Antill wrote:
The attached patch implements the full relabel audit event (Ie. an
audit event occurs when a full relabel occurs, ie. when /.autorelabel
exists at boot).
Note that although the code is correct, this patch doesn't actually
work due to kernel bugs[1].
It'll be in Fedora development as part of policycoreutils-1.30.10-3
onwards.
[1] see the thread on linux-audit if you want the details.
Hmmm...what is it that you actually want to do here? If you only care
about auditing autorelabel events, then I'd suggest generating the audit
message from the autorelabel portion of rc.sysinit (via a helper, I
suppose), not from setfiles itself. If you want to audit all full
relabels, then you need to instrument more than setfiles (e.g.
restorecon -R / works just as well), and of course, you potentially need
to do something at the kernel level with audit filters or auditallow
rules in policy if you truly want to capture all relabels. And, of
course, just auditing it when they happen to pass "/" as an argument
isn't very reliable.
Not sure which thread you are referring to; I don't see prior discussion
of a relabel audit event in the linux-audit archives.
--
Stephen Smalley
National Security Agency
12:47 p.m.
On Fri, 2006-05-26 at 13:05 -0400, Stephen Smalley wrote:
On Thu, 2006-05-25 at 17:01 -0400, James Antill wrote:
> The attached patch implements the full relabel audit event (Ie. an
> audit event occurs when a full relabel occurs, ie. when /.autorelabel
> exists at boot).
> Note that although the code is correct, this patch doesn't actually
> work due to kernel bugs[1].
>
> It'll be in Fedora development as part of policycoreutils-1.30.10-3
> onwards.
>
> [1] see the thread on linux-audit if you want the details.
Hmmm...what is it that you actually want to do here? If you only care
about auditing autorelabel events, then I'd suggest generating the audit
message from the autorelabel portion of rc.sysinit (via a helper, I
suppose), not from setfiles itself.
This is all that we care about, but the solution of creating a helper
to just be called before setfiles was considered suboptimal against just
putting the code inside setfiles (I know Steve is very much against
anything which acts like logger for the audit subsystem).
Not sure which thread you are referring to; I don't see prior
discussion
of a relabel audit event in the linux-audit archives.
The thread is for the kernel problem that makes the above patch not
actually work, see the thread "Re: audit 1.2.2 released".
--
James Antill <jantill(a)redhat.com>
1:03 p.m.
New subject: [redhat-lspp] Re: [patch] Full relabel audit event
On Fri, 2006-05-26 at 13:47 -0400, James Antill wrote:
On Fri, 2006-05-26 at 13:05 -0400, Stephen Smalley wrote:
> Hmmm...what is it that you actually want to do here? If you only care
> about auditing autorelabel events, then I'd suggest generating the audit
> message from the autorelabel portion of rc.sysinit (via a helper, I
> suppose), not from setfiles itself.
This is all that we care about, but the solution of creating a helper
to just be called before setfiles was considered suboptimal against just
putting the code inside setfiles (I know Steve is very much against
anything which acts like logger for the audit subsystem).
I don't see the point when a) you only want it in that one case, b) it
doesn't prevent trivial bypass in any way (e.g. by using restorecon, by
rolling your own program to do it, by running setfiles on /* rather than
just /, ...), and c) you aren't capturing any information that cannot be
determined by the caller of setfiles in the first place (just the fact
of a mass relabel and the final exit status).
Note btw that setfiles already provides three different ways to log
actual changes in file contexts, the original -v verbose mode, and the
-l (log via syslog) and -o <file> (log to file) modes introduced later
by Red Hat. That at least provides detailed information that the caller
couldn't determine otherwise.
The thread is for the kernel problem that makes the above patch not
actually work, see the thread "Re: audit 1.2.2 released".
--
Stephen Smalley
National Security Agency
9:08 a.m.
New subject: [redhat-lspp] Re: [patch] Full relabel audit event
On Friday 26 May 2006 14:03, Stephen Smalley wrote:
I don't see the point when a) you only want it in that one case,
We do this already in several places. For example, we instrumented usermod,
but not chage. It was documented in the Security Target that usermod should
be used to alter user account attributes.
b) it doesn't prevent trivial bypass in any way (e.g. by using
restorecon,
by rolling your own program to do it, by running setfiles on /* rather than
just /, ...), and
Its not meant to be bulletproof. Its purpose is to document that a full
relabel has occurred before any user can log in. During the boot process, no
one can log in so nothing evil should happen.
Note btw that setfiles already provides three different ways to log
actual changes in file contexts, the original -v verbose mode, and the
-l (log via syslog) and -o <file> (log to file) modes introduced later
by Red Hat. That at least provides detailed information that the caller
couldn't determine otherwise.
It was determined that we only need 1 record, not all the changes.
-Steve
8:22 a.m.
New subject: [redhat-lspp] Re: [patch] Full relabel audit event
On Friday 26 May 2006 13:05, Stephen Smalley wrote:
Hmmm...what is it that you actually want to do here?
We need to meet the requirements for LSPP where there is a relabel on boot,
but we do not want a record for each file that was touched. It was discussed
on the LSPP telecon a while back that just one record was sufficient.
If you only care about auditing autorelabel events, then I'd
suggest
generating the audit message from the autorelabel portion of rc.sysinit (via
a helper, I suppose), not from setfiles itself.
This is a shell script and cannot connect to libaudit.
If you want to audit all full relabels, then you need to instrument
more
than setfiles (e.g. restorecon -R / works just as well), and of course, you
potentially need to do something at the kernel level with audit filters or
auditallow rules in policy if you truly want to capture all relabels.
We get relabels by monitoring the setxattr syscall. But during bootup before
going interactive, we just want 1 message.
-Steve
6789
days inactive
6794
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
James Antill -
Stephen Smalley -
Steve Grubb