Bug 883043 - audit: systemd should truncate messages to be no longer than 4K
Summary: audit: systemd should truncate messages to be no longer than 4K
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-03 16:55 UTC by Eric Paris
Modified: 2013-05-16 02:56 UTC (History)
10 users (show)

Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-16 02:56:31 UTC
Type: Bug


Attachments (Terms of Use)

Description Eric Paris 2012-12-03 16:55:25 UTC
When systemd sends a userspace AVC message (typically because a user tried to start/stop/query a service they didn't have permission for) the message can be longer than 4k.  The audit system truncates messages to 4k (fscking dumb, but that's what it does).  Systemd should not send messages so long they are likely to hit this.  From what I have seen, it is cmdline= which is most likely to have such excessively long input that the useful part of the audit message is lost.

Comment 1 Lennart Poettering 2013-01-13 23:06:04 UTC
So what should we do? When generating audit messages truncate all strings we include? To which length?

Comment 2 Eric Paris 2013-01-14 19:12:02 UTC
I've decided to reassign to audit userspace.  This is not a kernel problem, and not a systemd problem either.

The auditd daemon is once again doing something stupid.  When we were doing execve audit userspace was stupidly truncating messages to 4096.  In the kernel I broke execve arguments into multiple records.  Had I been bolder and wiser back in the day I would have refused to make such a change.

There is no way to do such a breakup on a user generated audit message.  It darn well can be longer than 4k.  This is broken in the audit libraries.  Please fix the audit libraries.

Comment 3 Steve Grubb 2013-01-16 19:12:40 UTC
I don't see any limit that cuts things down to 4K. The buffer is a little bigger than 8K so that it has room for 2 paths at MAX_PATH length + 2 SE Linux contexts + 268 bytes for other information. Its currently 8970 bytes. Can you tell me a little more about how the event was being generated? Specifically, what audit function was being used?

Comment 4 Steve Grubb 2013-01-28 16:29:27 UTC
Any info on reproducing this problem?

Comment 5 Steve Grubb 2013-01-28 17:13:08 UTC
OK, took a look... in src/core/selinux-access.c, we find this:

char buf[LINE_MAX];

vsnprintf(buf, sizeof(buf), fmt, ap);
audit_log_user_avc_message(get_audit_fd(), AUDIT_USER_AVC, buf, NULL, NULL, NULL, 0);

So, what is LINE_MAX? Its not defined anywhere in systemd's code. So, it must be from /usr/include/bits/posix2_lim.h where its defined as 2K. 

As stated previously, the audit system allows messages that are a bit over 8K. So, I think you can safely increase the buffer from 2K to 4K or so. Transferring back to systemd since its code is the limiting factor.

Comment 6 Lennart Poettering 2013-02-13 18:38:48 UTC
I have now changed our code to use a dynamically sized buffer. This way we don't have to make any assumptions about the audit buffer. 

If libaudit expects people to be able to use statically sized buffers, then it should probably export some suggested size values for that. Until then, doing this dynamically sounds safer for us, so that we don't run in this again.

Comment 7 Steve Grubb 2013-02-14 11:40:02 UTC
Libaudit.h defines MAX_AUDIT_MESSAGE_LENGTH. You would want to use a little less than this because that is the maximum including all the things that libaudit adds like terminal, host, exe name, and success/fail. 

Out of curiosity, do you really feel sure about dynamic allocations in general? You don't worry about heap fragmentation? The audit daemon code uses stack based buffers everywhere possible so that any chance of heap fragmentation is minimized.

Thanks for the update...

Comment 8 Fedora Update System 2013-04-10 20:10:32 UTC
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1

Comment 9 Fedora Update System 2013-04-11 23:23:24 UTC
Package systemd-201-2.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2013-04-15 23:58:02 UTC
Package systemd-201-2.fc18.4:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-04-18 02:35:17 UTC
Package systemd-201-2.fc18.5:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2013-05-07 13:37:44 UTC
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6

Comment 13 Fedora Update System 2013-05-09 10:00:35 UTC
Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2013-05-16 02:56:31 UTC
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.