1:08 p.m.
The userspace group is attempting to write new applications which will
dynamically profile system startup and preload applications and data so
that they are hot in the kernel when they are needed.
http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded
They need to see all of the exec and open calls from the system so they
can profile what is needed. They discovered that the audit system does
exactly what they need except one problem. It writes all of the exec
and open call records to disk which very quickly gets too large. All
they want is a way to tell the audit system to send a message to the
audit dispatcher but not to log to disk. This isn't so easy as it means
that audit has to somehow parse the messages rather than just quickly
write them.
Since the plan is to always have the audit system always emit these
rules on all non-server type systems it really isn't reasonable to have
them written to disk. We suggested they look at system-tap, which was
able to give them the information, but it meant compiling a kernel
module for every kernel and had all sorts of maintenance nightmares
(from what I'm told) so they came back to me.
What I'm considering is a new 'flag' which audit rules can be loaded
with which indicates to use the new 'no-log' netlink socket. The kernel
would then have 2 netlink sockets. One will continue to talk to auditd
the other straight to a dispatcher. No changes will be made in any way
to the way we handle messages or panic on message loss to the 'normal'
audit queue. I'm thinking the second netlink socket will be a 'best
effort' audit system. Messages may be dropped without indication it
should run at a lower priority, blah blah blah. It would allow the very
flexible and powerful audit system to be used for profiling and data
collection for non-security relevant applications.
I want thoughts on such a proposal. Obviously I'm going to ahve to put
some real thought/care into how to handle 'overlapping' rules between
security and non-security and stuff like that, but as a general idea
what do people think?
-Eric
2:11 p.m.
Eric Paris wrote:
The userspace group is attempting to write new applications which
will
dynamically profile system startup and preload applications and data so
that they are hot in the kernel when they are needed.
http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded
They need to see all of the exec and open calls from the system so they
can profile what is needed. They discovered that the audit system does
exactly what they need except one problem. It writes all of the exec
and open call records to disk which very quickly gets too large. All
they want is a way to tell the audit system to send a message to the
audit dispatcher but not to log to disk. This isn't so easy as it means
that audit has to somehow parse the messages rather than just quickly
write them.
Do these folks also want to run audit for security-related events? If
not, then they could just configure a small audit file or two that
wraps/rotates, or use the NOLOG log format.
Since the plan is to always have the audit system always emit these
rules on all non-server type systems it really isn't reasonable to have
them written to disk. We suggested they look at system-tap, which was
able to give them the information, but it meant compiling a kernel
module for every kernel and had all sorts of maintenance nightmares
(from what I'm told) so they came back to me.
What I'm considering is a new 'flag' which audit rules can be loaded
with which indicates to use the new 'no-log' netlink socket. The kernel
would then have 2 netlink sockets. One will continue to talk to auditd
the other straight to a dispatcher. No changes will be made in any way
to the way we handle messages or panic on message loss to the 'normal'
audit queue. I'm thinking the second netlink socket will be a 'best
effort' audit system. Messages may be dropped without indication it
should run at a lower priority, blah blah blah. It would allow the very
flexible and powerful audit system to be used for profiling and data
collection for non-security relevant applications.
Is that what we want? Would it be better to work on a way to solve
their maintenance nightmare with systemtap?
I want thoughts on such a proposal. Obviously I'm going to ahve
to put
some real thought/care into how to handle 'overlapping' rules between
security and non-security and stuff like that, but as a general idea
what do people think?
Sounds complicated, but you knew that already.
-- ljk
-Eric
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
4 p.m.
On Tue, 2008-05-27 at 14:08 -0400, Eric Paris wrote:
I want thoughts on such a proposal. Obviously I'm going to ahve
to
put
some real thought/care into how to handle 'overlapping' rules between
security and non-security and stuff like that, but as a general idea
what do people think?
At the risk of sounding like "we should take over the world", I think it
actually should be a good thing to have more users relying on the audit
subsystem, so I liked the idea.
Previously, on this same mailing list, we once discussed about using
fields to route records across different systems. Perhaps it's time for
us to have a real look at a more generic solution for this? (Not that
I'm against adding another field, but since record routing is necessary
for several reasons, wouldn't it be desirable to have the right
infrastructure in place to handle those, say, in auditctl?)
-Klaus
--
Klaus Heinrich Kiwi <klausk(a)linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center
4:24 p.m.
--- Klaus Heinrich Kiwi <klausk(a)linux.vnet.ibm.com> wrote:
On Tue, 2008-05-27 at 14:08 -0400, Eric Paris wrote:
> I want thoughts on such a proposal. Obviously I'm going to ahve to
> put
> some real thought/care into how to handle 'overlapping' rules between
> security and non-security and stuff like that, but as a general idea
> what do people think?
In theory I'm behind this 100%.
At the risk of sounding like "we should take over the
world", I think it
actually should be a good thing to have more users relying on the audit
subsystem, so I liked the idea.
In practice, we tried this very thing in a Unix system (that you
can still buy, but not for too much longer). We convinced the people
implementing advanced resource accounting to do so by adding audit
record types with the information they required. Simple, clean,
saved them about a year on their development time.
Of course, just before the feature was to be released some joker
came along and insisted that the "overhead" of including audit "just
to do accounting" was ruinous. They threw away that implementation
and did a new infrastructure from scratch that was slow, buggy, and
consumed far more resources than the audit based implementation,
but that didn't meet their requirements. Needless to say, the original
audit based implementation was blamed for these problems.
My practical advice is to discourage the use of the audit system
for anything except security audit trails. People who don't do
security tend to have a hard time dealing with the reliability
and data rate requirements that drive the design of an audit
system, and will fix* critical audit system behaviors to better
suit other needs.
Previously, on this same mailing list, we once discussed about using
fields to route records across different systems. Perhaps it's time for
us to have a real look at a more generic solution for this? (Not that
I'm against adding another field, but since record routing is necessary
for several reasons, wouldn't it be desirable to have the right
infrastructure in place to handle those, say, in auditctl?)
----
* fix - in the veterenary sense of the word.
Casey Schaufler
casey(a)schaufler-ca.com
6051
days inactive
6052
days old
linux-audit@lists.linux-audit.osci.io
3 comments
4 participants
participants (4)
-
Casey Schaufler -
Eric Paris -
Klaus Heinrich Kiwi -
Linda Knippers