audit 1.0.11 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Fix memory leaks in aureport & ausearch
- Fix auditd reconfig to change mail accts, too
- Fix stray pointer in sorting of aureport
- Added new message type
- Add results to all DAEMON messages
- Fix parsing of daemon messages
I did testing this weekend and found the above problems.
Please let me know if there are any problems with this release.
-Steve
18 years, 12 months
audit 1.0.10 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Add --failed/success flags to aureport to select specific events for reports
- Add --summary to get totals of reported objects
- Add ability to force log rotation by sending sigusr1 to auditd
- Add -i flag to auditctl to ignore errors when reading rules from a file
- Reformat aureports so date & time are always given
- Add cron script for log rotation to docs
This release finishes up work on aureport. You can now select failed or
successful events for the reports. The default is both. There is a new
--summary option that totals whatever the main object of the report is. This
is helpful for getting a quick idea of what's happening on the machine.
Another feature is being able to force log rotation on demand. This works with
a cron script that can be installed for daily rotation if a site has that
kind of need. The cron script is not installed by default.
auditctl now has a new flag, -i, to ignore errors when reading rules from a
file.
Please let me know if there are any problems with this release.
Thanks,
-Steve
19 years
Re: [PATCH] (1/2) new audit filter allows excluding messages by type (kernel)
by Dustin Kirkland
On 11/3/05, Steve Grubb <sgrubb(a)redhat.com> wrote:
> On Thursday 03 November 2005 08:58, Amy Griffis wrote:
> > What about someone running a kernel without CONFIG_AUDITSYSCALL? With
> > this implementation, they wouldn't be able to use this filtering at
> > all. That doesn't make any sense, since filtering audit record types
> > is inherently unrelated to syscalls. This filtering applies to audit
> > in general, so it should live entirely in audit.c.
>
> It might be tricky to untangle. I think it uses functions that only live in
> that file. I think its worth looking into, though
I'm looking into it.
It looks like audit_comparator() would have to be externalized, which
shouldn't be a problem.
The bigger issue is the fact that the messages to filter out are stored
in the audit_filter_list, and **all** of the audit rules code (ie,
audit_add_rule, audit_del_rule, etc) live in auditsc.c
One option would be to create a new structure to hold the list of
message types to exclude, and create new netlink aware functions to
populate and clear this list from userspace. However, that's grossly
duplicating the work that already present for the rest of the filter
rules lists.
It's perhaps arguable that the rules filtering code should perhaps be in
a file of it's own? auditrl.c? Of the other rule lists, at least
AUDIT_FILTER_TASK and AUDIT_FILTER_WATCH are not inherently tied to
syscalls, so AUDIT_FILTER_EXCLUDE doesn't seem that egregious.
But those changes would belong in a patch of it's own, which I'll be
happy to review and test if you provide. But for now, I'm going to move
on to more pressing matters and perhaps I'll look into that later.
:-Dustin
19 years
File System Watch Limits
by Steve Grubb
Hi,
Someone is trying to use the audit system's watch implementation. They have a
requirement to watch any changes to /lib & /user/lib and lots of other files.
At first they placed a watch on the directory thinking that it would get all
changes. I pointed out that that catches meta-data updates and could miss
some kinds of events on the files themselves. They created a shell script
that places an audit rule for each file in the directory.
At about 4500 files this quit working. The events aren't generated and
auditctl -l stops listing rules. By their estimate, they need to watch
approximately 90,000 files. 4500 falls far short of what's required.
Anyone have ideas about how to handle this kind of situation? I think we need
an elegant way to handle this.
-Steve
19 years
Re: [PATCH] (0/2) new audit filter allows excluding messages by type
by Dustin Kirkland
I see now that Steve has responded as well, But I was in the middle of drafting a response, so some of this may have already been covered.
On 11/3/05, Amy Griffis <amy.griffis(a)hp.com> wrote:
> On Wed, Nov 02, 2005 at 04:27:34AM -0500, Dustin Kirkland wrote:
> > On 11/1/05, Dustin Kirkland <dustin.kirkland(a)us.ibm.com> wrote:
> > > The interface to exclude messages of IPC type looks like:
> > > auditctl -a exclude,always -F "msgtype=IPC"
> >
> > Just now thinking about this... This might be a bit verbose for what
> > is truly needed. That is, the "always" part, and even the "msgtype"
> > should probably be implicit.
>
> Yes, definitely. I am in favor of a separate option.
Agreed. That's easy enough to do, even if the underlying implementation
is actually the rules functionality.
> > In which case, we might offer a shortcut interface for excluding
> > audit messages by type to use a new "-E" parameter:
> >
> > auditctl -E "type=IPC" -E "type>1400"
>
> Using the hard numbers is not a good idea. We want to abstract that
> from the user. It would be better to define an alias that comprises
> an event group. For example:
>
> auditctl -E user
I agree with aliasing. I think we should make it as easy as possible on
the user. But there's no reason to cripple the user's ability to
specify the numbers as well. There are several other places in the
auditctl code that accepts numbers or strings (user/uid, group/gid), so
I think we should continue to provide this flexibility in these cases as
well.
> > If you want to support excluding a specific message type, then you
> could accept the syntax:
>
> auditctl -E AUDIT_AVC
>
> or perhaps more preferably:
>
> auditctl -E avc
>
> where avc translates to message type AUDIT_AVC.
I say that we just drop the AUDIT_ from any message types and use that.
The AUDIT_ is understood.
> Providing the capability to exclude single messages or larger groups
> of messages should suffice. I don't think it benefits the user to
> support the >,< operators in this case.
I agree that it 'should' suffice to most users, but the audit_operators
code is already there for our use and it really provides infinite
flexibility and range specification beyond what few use cases you and I
can foresee today. It doesn't cost us anything extra to give >,<,>=,<=
so I think we should give the admin as much flexibility as possible.
> Additionally, I don't think it makes sense to support the exclusion of
> any single message type defined in the header file. Some message
> types, like AUDIT_PATH, don't stand on their own, but belong to a
> greater subset. If we can identify message types that stand on their
> own, then we can support excluding those on their own, as well as in
> part of an event group.
Again, it doesn't cost us anything to offer this as a possibility. In
fact, it would take more code to forbid users from excluding a single
message type.
:-Dustin
19 years
[PATCH] (0/2) new audit filter allows excluding messages by type
by Dustin Kirkland
RBACPP places requirements on "selective audit".
FAU_SEL.1
Selective Audit
FAU_SEL.1.1
The TSF shall be able to include or exclude auditable events from the
set of audited events based on the following attributes:
(a) Object identity, user identity, subject identity, host identity, and
event type
(b) Users belonging to a specified Role and Access types (e.g. delete,
insert) on a particular object
---
The following patches add the capabilities required to userspace and the
kernel to allow administrators to filter out audit records based on the
event type.
The audit message type is known as early on as in the call to
audit_log_start(), and thus, placing a check against the filter there
would save the kernel considerable effort allocating buffers and
printing them when the record would ultimately be thrown away (if it
were filtered later). I placed this call just after the verification of
audit_initialized.
When coupled with the previous patches I submitted adding support for
advanced operators (<, >, <=, >=), this gives an administrator
considerable flexibility in saving a running kernel time and resources
if particular message types are not of interest.
Along those lines, there has been some discussion as to whether this
filtering belongs in the kernel or in auditd (userspace). The patches
I'm submitting now add the functionality to the kernel, in fact. It's
my initial feeling that this may well provide enough of a performance
benefit to merit it's presence there. But I expect this might introduce
a discussion here .... \/
--
The interface to exclude messages of IPC type looks like:
auditctl -a exclude,always -F "msgtype=IPC"
or
auditctl -a exclude,always -F "msgtype=1303"
The interface to exclude userspace messages looks like:
auditctl -a exclude,always -F "msgtype>=1100" -F "msgtype<=1199"
Note that we can certainly teach the audit userspace to recognize many
constant strings to keep administrators from having to come up with
these magic numbers on their own. Thus, you could use something more
like -F "msgtype>=FIRST_USER_MSG" -F "msgtype<=LAST_USER_MSG", and so
on.
Also note that if you exclude messages of a particular type, its
auxiliary messages are nuked as well.
Patches follow in adjacent emails. Comments welcome.
:-Dustin
19 years
audit 1.0.9 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Updated message types that auditd recognizes
- Added a couple more message types
- Added new standard logging format function
- Update default config
- Make ausearch -m take a list of message types
This update is needed to allow use of the new audit message types.
Please let me know if there are any problems.
Thanks,
-Steve
19 years
proposed interface changes for filesystem audit
by Amy Griffis
Hello,
The current approach to filesystem auditing requires some changes to
the kernel-userspace interface. We've discussed these in various
conversations on IRC, but Steve asked me to summarize the changes here
so we can review them collectively.
Comments appreciated.
Thanks,
Amy
Kernel-Userspace Interface Changes
----------------------------------
Following are the proposed changes to the kernel-userspace interface:
(1) A new version of struct audit_rule that supports string fields.
struct audit_rule_xprt {
uint32_t flags;
uint32_t action;
uint32_t field_count;
uint32_t mask[AUDIT_BITMASK_SIZE];
uint32_t fields[AUDIT_MAX_FIELDS];
uint32_t values[AUDIT_MAX_FIELDS];
uint32_t buflen;
char buf[0];
};
This struct adds two fields, buf and buflen, to the fields
currently defined in struct audit_rule. The field buf is a
variable length string that could potentially hold any number of
null-delimited string fields. When defining a string field, the
fields[] element specifies the field type and the values[] element
specifies the length of the string field. String fields in the
buffer are processed in the order in which they occur in the
fields[],values[] arrays.
In the case of filesystem watches, the string path is converted to
an inode number for use in the actual filter. If we decide to
support other string fields in filters, the performance impact of
doing a strcmp() should be understood.
(2) New netlink message types for adding, removing and listing rules
with a string field, i.e.:
AUDIT_ADD_RULE
AUDIT_DEL_RULE
AUDIT_LIST_RULES
When the kernel receives a message type of AUDIT_ADD, AUDIT_DEL,
or AUDIT_LIST, it will interpret the data using the older
audit_rule struct.
(3) A new rule field type, i.e.:
AUDIT_PATHNAME
(4) To accommodate these changes, libaudit must provide new routines
for adding, removing and listing rules using the new struct and
message types, i.e.:
extern int audit_req_rules_buf(int fd);
extern int audit_add_rule_buf(int fd, struct audit_rule_xprt *rule);
extern int audit_del_rule_buf(int fd, struct audit_rule_xprt *rule);
(5) Libaudit must add struct audit_rule_xprt to the union in
struct audit_reply.
Command Line Changes
--------------------
The following changes would be necessary for the auditctl command to
support the proposed changes to the kernel-userspace interface:
(1) A new field allowed for the -F option, i.e.:
-F path=/home/watchme
Additionally, the inode and path fields should not be specified in
the same rule, as the inode field would be ignored.
(2) A set of filesystem-related aliases for groups of system calls.
Currently, one alias "all" is provided that maps to the full set
of system calls on a given arch.
Here are some examples of other aliases that could be provided:
fs-create: creat,link,mkdir,mknod,open,rename,symlink
fs-remove: rename,rmdir,unlink
fs-attr: chmod,chown,fchmod,fchown,fremovexattr,fsetxattr,lchown,
lremovexattr,lsetxattr,removexattr,setxattr,truncate,utime(s)
fs-all: all filesystem-related syscalls
(3) If backward compatibility with the -w,-W, and -p options is
desired, auditctl could be modified to populate an audit_rule_xprt
struct with the provided path string and a set of syscalls that
maps to the previous behavior. For example, "-p w" would map to
the syscalls specified by the fs-create, fs-remove and fs-attr
aliases above, while -w by itself would map to the fs-all alias.
19 years
New Audit types
by Matt Anderson
Here are the four types that were required for Cups
AUDIT_LABELED_EXPORT
AUDIT_UNLABELED_EXPORT
AUDIT_LABEL_OVERRIDE
AUDIT_LABELED_LEVEL_CHANGE
LSPP has the following printing audit requirements:
All attempts to export labeled data
All attempts to export unlabeled data
Overriding the label on a printout
Changing a device from labeled to unlabeled
Changing a device from unlabeled to labeled
Changing the level of a labeled device
-matt
19 years
RE: [redhat-lspp] Re: New Audit types
by Chad Hanson
>
> I think you're missing a subtle point. Assume that the user has the
> permissions to read secret and write to an unlabeled media. Assume they
have
> properly allocated the device and are ready to do something.
>
> Given that, what is the correct action? LSPP says that its an auditable
event
> - it doesn't say it must be prevented. Should each program that does this
be
> patched or does a central mechanism in the kernel need to handle this?
I believe this should be covered by the existing syscall auditing such as
open and others. The LSPP doesn't state the auditing of the export has to be
any different than other fs auditing, just that it has to occur IMHO. The
additional requirement is the device allocation auditing requirements. An
audit analyst should *hopefully* be able to correlate what has been exported
given these events.
-Chad
19 years
