1:53 p.m.
Hi,
I was looking at my audit logs and have a question. Does the SE Linux AVC
denial messages constitute something that ought to be in the audit logs? Or
does it belong in syslog?
I agree that it is important information...just curious where it should really
live.
Thanks,
-Steve Grubb
1:51 p.m.
On Tue, 2005-01-04 at 14:53, Steve Grubb wrote:
I was looking at my audit logs and have a question. Does the SE Linux
AVC
denial messages constitute something that ought to be in the audit logs? Or
does it belong in syslog?
I agree that it is important information...just curious where it should really
live.
It belongs in an audit log, but you could certainly have multiple audit
logs, with one dedicated to SELinux (i.e. MAC) audit messages.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:08 p.m.
On Tuesday 04 January 2005 14:51, Stephen Smalley wrote:
It belongs in an audit log, but you could certainly have multiple
audit
logs, with one dedicated to SELinux (i.e. MAC) audit messages.
One of the reasons I'm asking is because its not controlable via the audit
interface. Without any audit rules loaded, you get SE Linux audit messages
filling up the logs.
If you used laus, for example, does avc messages wind up in the logs?
-Steve Grubb
2:28 p.m.
On Tue, 2005-01-04 at 15:08, Steve Grubb wrote:
On Tuesday 04 January 2005 14:51, Stephen Smalley wrote:
> It belongs in an audit log, but you could certainly have multiple audit
> logs, with one dedicated to SELinux (i.e. MAC) audit messages.
One of the reasons I'm asking is because its not controlable via the audit
interface. Without any audit rules loaded, you get SE Linux audit messages
filling up the logs.
If you used laus, for example, does avc messages wind up in the logs?
Keep in mind that when we originally wrote SELinux, there was no kernel
audit framework, so we simply used the existing kernel logging
infrastructure, but we always expected to migrate to using a real audit
subsystem once one became available.
I don't see any real benefit to moving the SELinux policy audit rules
out of the policy and into a separate audit rule database, particularly
as you would have to then duplicate the policy abstractions in your
audit policy. But I don't see why that should prevent you from handling
SELinux audit messages via auditd and directing them to a MAC audit log
file. The kernel logging infrastructure can't really handle the
potential load of SELinux audit, and you don't really want SELinux audit
messages intermingled with other kernel log messages.
LaUS wasn't integrated with SELinux at all.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:51 p.m.
On Tuesday 04 January 2005 15:28, Stephen Smalley wrote:
I don't see any real benefit to moving the SELinux policy audit
rules
out of the policy and into a separate audit rule database, particularly
as you would have to then duplicate the policy abstractions in your
audit policy.
I'm not really thinking about moving the rules. Just about how to silence it
or select what kinds of messages it sends to auditd.
-Steve Grubb
2:52 p.m.
On Tue, 2005-01-04 at 15:51, Steve Grubb wrote:
I'm not really thinking about moving the rules. Just about how to
silence it
or select what kinds of messages it sends to auditd.
The policy lets you configure what is audited (via dontaudit rules to
selectively suppress auditing of denials and via auditallow rules to
selectively enable auditing of grantings). What more do you need?
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:22 p.m.
On Tuesday 04 January 2005 15:52, Stephen Smalley wrote:
The policy lets you configure what is audited (via dontaudit rules
to
selectively suppress auditing of denials and via auditallow rules to
selectively enable auditing of grantings).
But wouldn't this mean the admin would have to have policy source installed?
That's far too messy.
What more do you need?
auditctl -selinux no_avc
;)
-Steve Grubb
3:26 p.m.
On Tue, 2005-01-04 at 16:22, Steve Grubb wrote:
But wouldn't this mean the admin would have to have policy source
installed?
That's far too messy.
No different than making any other policy change. Of course, it is
possible to directly manipulate binary policies via libsepol, and we
already have some examples of such manipulation, e.g. to set boolean
defaults prior to loading, to rebuild the users database via genpolusers
without policy source, etc. So you could build a tool that allowed
changes to the policy audit rules without full policy sources around,
and the binary policy module work by Tresys would be a more general
solution once it matures.
> What more do you need?
auditctl -selinux no_avc
Running SELinux with no auditing seems a bit unwise, as you then have
nothing to go on other than a mysterious EACCES. But you could
certainly implement a complete audit disable for SELinux either in
SELinux itself or in the kernel audit framework (but for the latter, the
audit_log* interfaces would likely need to take an additional argument
identifying the caller as SELinux vs. some other caller).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
9:33 p.m.
This is just my opinion though, the auditd should blindly accept and
and consume messages from kernel. It should not care what it has got.
What to be logged should be determined by policy settings.
Actually I'm working on some log filter plug-in for auditd that will be
loaded when auditd starts. It works just like ulogd's interpreter.
The filter does parse the aduit log messages and does what it should
do if necessary, i.e. writes into /var/log/message for AVC warnings,
sends alert message to admin when it detects some attacks, etc.
Current auditd implementation does not have interfaces to pass audit log
messages to other filter. It seems it is becoming a bit complicated, a big
monolithic binary, I'd like to request to modify auditd to add APIs that
loading filter plug-in's and pass audit log messages to them.
I can contribute some of my work if it is interesting to the author.
-- Junji Kanemaru
Linon Inc.
Tokyo Japan
10:06 p.m.
Hi,
First, I'd like to say that the current implementation is much further
developed than the 0.5.6 release. I'm being held up in releasing new code,
temporarily. Hopefully that will be resolved soon.
On Tuesday 04 January 2005 22:33, Linux wrote:
Current auditd implementation does not have interfaces to pass audit
log
messages to other filter.
This is true for 0.5.6. I have started a little work for passing messages
along via dbus. If you have other ideas, say so.
It seems it is becoming a bit complicated, a big
monolithic binary, I'd like to request to modify auditd to add APIs that
loading filter plug-in's and pass audit log messages to them.
Hopefully not. I'm adding the basic functionality that's demanded of any audit
daemon. Its not even 18K in size so it can't be big and monolithic. :)
I can contribute some of my work if it is interesting to the author.
Yes, I'm interested. Post some patches or contact me offlist. Maybe I can put
some things into the next release.
-Steve Grubb
5:47 p.m.
I don't know for sure but on 12/22/04 SuSE posted an update to SLES9 on
their maintenance page with the title "Optional update for EAL4
certification" and this description:
This package contains the configuration script and data
needed to set up the Common Criteria CAPP/EAL4 system
configuration certified on IBM hardware.
Based on this, I would guess they're done with their CAPP evaluation
and I'm pretty sure they're using LAuS.
-- ljk
Peter Martuccelli wrote:
On Tue, 2005-01-04 at 15:28, Stephen Smalley wrote:
>LaUS wasn't integrated with SELinux at all.
Does anyone know if LAuS has obtained EAL3/4 on 2.6?
Peter -
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
3:15 a.m.
On Tue, Jan 04, 2005 at 06:47:56PM -0500, Linda Knippers wrote:
Based on this, I would guess they're done with their CAPP
evaluation
and I'm pretty sure they're using LAuS.
We still use LAuS, yes. I'd love to switch to something based on LSM
if we could be sure it's certifiable.
Olaf
--
Olaf Kirch | Things that make Monday morning interesting, #2:
okir(a)suse.de | "We have 8,000 NFS mount points, why do we keep
---------------+ running out of privileged ports?"
3:35 a.m.
On Tue, Jan 04, 2005 at 06:47:56PM -0500, Linda Knippers wrote:
I don't know for sure but on 12/22/04 SuSE posted an update to
SLES9 on
their maintenance page with the title "Optional update for EAL4
certification" and this description:
This package contains the configuration script and data
needed to set up the Common Criteria CAPP/EAL4 system
configuration certified on IBM hardware.
Based on this, I would guess they're done with their CAPP evaluation
and I'm pretty sure they're using LAuS.
Yes, we are using LAuS and not SELinux.
The evaluation is not yet finished, but our last deliverables for it
have been done and shipped.
Ciao, Marcus
10:30 a.m.
On Tue, Jan 04, 2005 at 03:08:34PM -0500, Steve Grubb wrote:
On Tuesday 04 January 2005 14:51, Stephen Smalley wrote:
> It belongs in an audit log, but you could certainly have multiple audit
> logs, with one dedicated to SELinux (i.e. MAC) audit messages.
One of the reasons I'm asking is because its not controlable via the audit
interface. Without any audit rules loaded, you get SE Linux audit messages
filling up the logs.
If you used laus, for example, does avc messages wind up in the logs?
No, LAuS doesn't interface to SELinux.
-Klaus
2:02 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
Hi,
I was looking at my audit logs and have a question. Does the SE Linux AVC
denial messages constitute something that ought to be in the audit logs? Or
does it belong in syslog?
It's typical for audit requirements to mandate MAC policy auditing. I
know LSPP has this requirement for example.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
10:38 a.m.
On Tue, Jan 04, 2005 at 02:53:59PM -0500, Steve Grubb wrote:
I was looking at my audit logs and have a question. Does the SE Linux
AVC
denial messages constitute something that ought to be in the audit logs? Or
does it belong in syslog?
I agree that it is important information...just curious where it should really
live.
This kind of information is not relevant for CAPP, but is needed for LSPP
and similar profiles. For LSPP, it needs to be configurable in the same
way as other permission events, the profile requires that events can be
filtered by user identity.
-Klaus
7291
days inactive
7292
days old
linux-audit@lists.linux-audit.osci.io
16 comments
9 participants
participants (9)
-
Chris Wright -
Klaus Weidner -
Linda Knippers -
Linux -
Marcus Meissner -
Olaf Kirch -
Peter Martuccelli -
Stephen Smalley -
Steve Grubb