Audit: add support to match lsm labels on user audit messages
by Eric Paris
From: Miloslav Trmac <mitr(a)redhat.com>
Add support for matching by security label (e.g. SELinux context) of
the sender of an user-space audit record.
The audit filter code already allows user space to configure such
filters, but they were ignored during evaluation. This patch implements
evaluation of these filters.
For example, after application of this patch, PAM authentication logs
caused by cron can be disabled using
auditctl -a user,never -F subj_type=crond_t
Signed-off-by: Miloslav Trmac <mitr(a)redhat.com>
Acked-by: Eric Paris <eparis(a)redhat.com>
---
This patch was actually sent to list back on Nov 9, 2009 but
accidentally got dropped on the floor. I am resending the patch in
hopes that it will not get lost for the next merge window.
kernel/auditfilter.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index a706040..50307c1 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1259,6 +1259,18 @@ static int audit_filter_user_rules(struct netlink_skb_parms *cb,
case AUDIT_LOGINUID:
result = audit_comparator(cb->loginuid, f->op, f->val);
break;
+ case AUDIT_SUBJ_USER:
+ case AUDIT_SUBJ_ROLE:
+ case AUDIT_SUBJ_TYPE:
+ case AUDIT_SUBJ_SEN:
+ case AUDIT_SUBJ_CLR:
+ if (f->lsm_rule)
+ result = security_audit_rule_match(cb->sid,
+ f->type,
+ f->op,
+ f->lsm_rule,
+ NULL);
+ break;
}
if (!result)
14 years, 3 months
[PATCH] audit: filter userspace audit messages on selinux context
by Eric Paris
We have the information, so lets allow userspace audit messages to be
filtered based on the SELinux context. In particular this can be useful to
shut up the login events generated every time a cron job runs.
Signed-off-by: Eric Paris <eparis(a)redhat.com>
---
kernel/auditfilter.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 30ccdb9..6e251df 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1252,6 +1252,15 @@ static int audit_filter_user_rules(struct netlink_skb_parms *cb,
case AUDIT_LOGINUID:
result = audit_comparator(cb->loginuid, f->op, f->val);
break;
+ case AUDIT_SUBJ_USER:
+ case AUDIT_SUBJ_ROLE:
+ case AUDIT_SUBJ_TYPE:
+ case AUDIT_SUBJ_SEN:
+ case AUDIT_SUBJ_CLR:
+ result = security_audit_rule_match(cb->sid, f->type,
+ f->op, f->lsm_rule,
+ NULL);
+ break;
}
if (!result)
14 years, 3 months
Re: tty events
by Miloslav Trmac
Hello,
----- "Robert Daniels" <robertdaniels2009(a)gmail.com> wrote:
> I'm using pam_tty_audit and am collecting specific users, including root.
>
> When logged in as root, the tty events are sent to the plugin in near real-time.
> However, when logged in as a user, the events are cached someplace and are eventually flushed to the dispatcher/plugin.
> The other odd thing is the cached user events are in a single event, and is a collection of multiple tty commands stored into one chunk of data.
> I've looked at the source code but do not see where this caching takes place.
For "raw mode" TTYs (e.g. the bash command-line editing environment, vi), newline is not a reliable "command" indicator, so the keystrokes are queued until the buffer (which is 4096 bytes) is full.
Programs that accept something like "commands" should send USER_TTY records whenever a "command" is entered; this also flushes the buffer, creating the TTY record containing keystrokes to that point. If I remember correctly, this is implemented for bash and programs that use the readline library.
The problem is that only programs running as root are allowed to send audit records from user-space, so the USER_TTY records sent from unprivileged programs are ignored and do not flush the buffer.
> I'd like to know if there is a setting to disable this caching and send the events in real time, or at least have a way to break these events up, and acquire a timestamp that matches when the events took place.
I'm afraid there isn't currently a practical way to do this. (bash --noediting) does not use the raw mode, but I'd hardly consider that practical.
Mirek
14 years, 3 months
creating and inserting audits
by Nestler, Roger - IS
Using syslog it seems straight forward to insert a new message , 'syslog (LOG_NOTICE, "Hello This is just a notice")' for instance.
Does this capability exist already in linux audit and I'm just not seeing it???
Is it a bad idea to build and then to insert a custom audit/message, or any standard audit, into the audit.log file?
If so are there any problems to look out for , e.g event id/sequence number collisions, auparse or ausearch problems, formatting issues to adhere to???
Thanks
________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
14 years, 3 months
tty events
by Robert Daniels
I've written an audit plugin to collect statistical data.
I have collected a lot of data over the past few weeks, and the only puzzler
relates to tty data.
I'm using pam_tty_audit and am collecting specific users, including root.
When logged in as root, the tty events are sent to the plugin in near
real-time.
However, when logged in as a user, the events are cached someplace and are
eventually flushed to the dispatcher/plugin.
The other odd thing is the cached user events are in a single event, and is
a collection of multiple tty commands stored into one chunk of data.
I've looked at the source code but do not see where this caching takes
place.
I'd like to know if there is a setting to disable this caching and send the
events in real time, or at least have a way to break these events up, and
acquire a timestamp that matches when the events took place.
Here is a snippet of one of these 'compound' events:
type=TTY (TTY)
pid=14778 (14778)
uid=501 (robert)
auid=501 (robert)
major=136 (136)
minor=3 (3)
comm="ssh" (ssh)
data=6563687F7F6E76207C2067726...[truncated]
("ech",<backspace>,<backspace>,"nv | grep SSH",<ret>,"service auditd
stop",<ret>,<up>,<backspace>,<backspace>,"art",<ret>,"su",
ret>,"password",<ret>,"service auditd stop",<ret>,<up>,<backspace>,
<backspace>,"art",<ret>,"ls",<ret>,"p",<backspace>,"ls",<ret>,"exit",
<ret>,"exit",<ret>)
- Robert
14 years, 3 months
Re: audit log not being rotated
by Daniel J Walsh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/04/2010 02:30 PM, Mike Williams wrote:
> On Sat, Sep 4, 2010 at 1:52 PM, Dominick Grift <domg472(a)gmail.com> wrote:
>
>> On Sat, Sep 04, 2010 at 01:24:33PM -0400, Mike Williams wrote:
>>>
>>> Any idea why one box out of three would behave differently? It is a
>>> worrisome difference.
>>
>> Audit does not use logrotate to rotate logs. I think it does that itself.
>> See /etc/audit/auditd.conf
>> Also the log can be rotated by running the auditd rc script: service auditd
>> rotate
>>
>>
> After lots of digging and, confirmed by your response, I now realize that
> logrotate is not being used. The cron file I mentioned uses the command you
> mentioned (service auditd rotate) to rotate the logs.
>
> I just compared /etc/auditd.conf and /etc/audit.rules on the system that was
> not rotating logs with one of the ones that has been rotating audit.log and
> they are identical.
>
> So, for me, my original question remains a puzzle. Why did it just work on
> two out of three boxes, but require adding a cron job to do "service auditd
> rotate" on the the third. Murphy's Law is in force here, the system that
> has not been rotating the logs is the one that is the most important, at
> least in terms of the number of people who use it.
>
> Mainly I'm concerned about what will happen on the update to f14, since the
> misbehaving system is now fixed.
>
> Mike
>
>
>
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
I would ask on the audit list.linux-audit(a)redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyGUlYACgkQrlYvE4MpobO2PgCbBarqt+aP+DFjo8/1IjwyY4sr
xfMAoL3zY1LvfoKNQtguhD5CGcLHxiUU
=kKWv
-----END PGP SIGNATURE-----
14 years, 3 months
Re: [patch RFC]: userspace crypto auditing, v2
by Miloslav Trmac
Hello,
Thanks for the comments.
----- "Eric Paris" <eparis(a)redhat.com> wrote:
> A couple functions I think you can safely drop a level of indentation
> include audit_log_crypto_op(), audit_filter_rules(), and maybe
> log_crypto_op() needs a helper function to cut down the indentation?
> Maybe not.
Fixed all of these.
> I really don't like %s in audit_log_format(). So unless its easy to
> prove that the string meets all the rules and always will meet the
> rules, please use audit_log_string() (and in this code I noticed that I
> could not verify 'operation' in this patch, which makes me very
> nervous.
The callers ensure that the inputs are trusted, but I did have untrusted input there at least once, so it is indeed safer.
Attached is an updated patch; in addition to the above changes, it also splits struct audit_crypto_op to three to avoid an union, making the code easier to read and more similar to other auxiliary data structures in auditsc.c.
Mirek
14 years, 3 months
Gavin Appleton is out of the office.
by Gavin Appleton
I will be out of the office starting 04/09/2010 and will not return until
04/10/2010.
On Paternity leave ! If urgent please contact TST MF front shop on 52580.
14 years, 3 months
[patch RFC]: userspace crypto auditing, v2
by Miloslav Trmac
Hello,
I'm posting these patches for early review again; users of the code are not in the kernel yet.
Changes since the previous version:
- New record type CRYPTO_AUDIT_CRYPTO_KEY_VALUE, to implement "basic" level from CC
- aureport handles events with multiple crypto records
Record types
------------
This patch set keeps the original single AUDIT_CRYPTO_USERSPACE_OP record type. Here is a description of all kinds of events that can happen, to facilitate discussion of the requested record types.
The following events cause creation of a CRYPTO_USERSPACE_OP record:
* context_new: A new "crypto context" (within which integer IDs are allocated) was
set up.
Fields: context ID
* context_del: A crypto context was destroyed.
Fields: context ID
* key_wrap: A key was wrapped using another key
Fields: context ID, wrapping algorithm name, [wrapping key], wrapped key
If wrapping key is not explicitly recorded, it is the storage master key
* key_unwrap: A key was unwrapped using another key
Fields: context ID, wrapping algorithm name, [wrapping key], wrapped key
If wrapping key is not explicitly recorded, it is the storage master key
* key_export: Key material was written to userspace
Fields: context ID, key algorithm, key
* key_import: Key material was read from userspace
Fields: context ID, key algorithm, key
* key_zeroize: Key object was cleared
Fields: context ID, key algorithm, key
CRYPTO_KEY_VALUE record may follow
* key_gen: A key or key pair was generated
Fields: context ID, key algorithm, key, [public key]
One or two CRYPTO_KEY_VALUE records may follow
* key_get_info: Information about a key was provided to userspace
Fields: context ID, key algorithm, key
* key_derive: A new key was derived from an existing key
Fields: context ID, key algorithm, source key, new key
* session_init: A new crypto operation context was created
Fields: context ID, [session ID], operation name, algorithm, [key]
session ID is missing for sessions that do not span more than one system call
* session_op: An operation within a session was performed
Fields: context ID, [session ID], operation name, algorithm, [input key]
* session_final: A session was finished
Fields: context ID, [session ID], operation name, algorithm
In all of the above, "key" in Fields means "integer key ID, longer-term ID byte string".
Looking at the record types proposed earlier, AUDIT_CRYPTO_STORAGE_KEY could perhaps use AUDIT_CRYPTO_PARAM_CHANGE_KERN, and all of the key_* events above can use AUDIT_CRYPTO_KEY_KERN. There is no good match for the session_* events.
I also think the KEY_VALUE data should use separate records to allow filtering them out while keeping the rest of the information - see below for rationale.
Patch description
-----------------
Three new records are defined; in each case output of records is caused by a syscall, and all other syscall-related data (process identity, syscall result) is audited in the usual records.
AUDIT_CRYPTO_STORAGE_KEY is used when a system-wide storage wrapping key is changed.
AUDIT_CRYPTO_USERSPACE_OP is used when any user-space program performs a crypto operation. To disable auditing these records by default and to allow the users to selectively enable them using filters, a new filter field AUDIT_CRYPTO_OP is defined; auditing of all crypto operations can thus be enabled using (auditctl -a exit,always -F crypto_op!=0).
AUDIT_CRYPTO_KEY_VALUE is used to record public key components when generating or zeroizing keys (as required for CC "basic" level auditing). The CRYPTO_KEY_VALUE record always immediately follows a CRYPTO_USERPACE_OP record that describes the performed operation. Unfortunately the key components can be quite large (a 4096-bit value results in a 1kB field in the record), but there does not seem to be any way to avoid this. It would probably be possible, as an optimization, to skip creating these records if the *_KEY_VALUE type is filtered out (-a type,never).
Attached for review are:
- A kernel patch
- An userspace audit patch
- A few example audit entries
Mirek
14 years, 3 months
