aboutsummaryrefslogtreecommitdiff
path: root/kernel/audit.c
AgeCommit message (Collapse)Author
2005-05-05Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.gitDavid Woodhouse
2005-05-03[NETLINK]: Synchronous message processing.Herbert Xu
Let's recap the problem. The current asynchronous netlink kernel message processing is vulnerable to these attacks: 1) Hit and run: Attacker sends one or more messages and then exits before they're processed. This may confuse/disable the next netlink user that gets the netlink address of the attacker since it may receive the responses to the attacker's messages. Proposed solutions: a) Synchronous processing. b) Stream mode socket. c) Restrict/prohibit binding. 2) Starvation: Because various netlink rcv functions were written to not return until all messages have been processed on a socket, it is possible for these functions to execute for an arbitrarily long period of time. If this is successfully exploited it could also be used to hold rtnl forever. Proposed solutions: a) Synchronous processing. b) Stream mode socket. Firstly let's cross off solution c). It only solves the first problem and it has user-visible impacts. In particular, it'll break user space applications that expect to bind or communicate with specific netlink addresses (pid's). So we're left with a choice of synchronous processing versus SOCK_STREAM for netlink. For the moment I'm sticking with the synchronous approach as suggested by Alexey since it's simpler and I'd rather spend my time working on other things. However, it does have a number of deficiencies compared to the stream mode solution: 1) User-space to user-space netlink communication is still vulnerable. 2) Inefficient use of resources. This is especially true for rtnetlink since the lock is shared with other users such as networking drivers. The latter could hold the rtnl while communicating with hardware which causes the rtnetlink user to wait when it could be doing other things. 3) It is still possible to DoS all netlink users by flooding the kernel netlink receive queue. The attacker simply fills the receive socket with a single netlink message that fills up the entire queue. The attacker then continues to call sendmsg with the same message in a loop. Point 3) can be countered by retransmissions in user-space code, however it is pretty messy. In light of these problems (in particular, point 3), we should implement stream mode netlink at some point. In the mean time, here is a patch that implements synchronous processing. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-03[PATCH] add new audit data to last skbChris Wright
When adding more formatted audit data to an skb for delivery to userspace, the kernel will attempt to reuse an skb that has spare room. However, if the audit message has already been fragmented to multiple skb's, the search for spare room in the skb uses the head of the list. This will corrupt the audit message with trailing bytes being placed midway through the stream. Fix is to look at the end of the list. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29[AUDIT] Requeue messages at head of queue, up to audit_backlogChris Wright
If netlink_unicast() fails, requeue the skb back at the head of the queue it just came from, instead of the tail. And do so unless we've exceeded the audit_backlog limit; not according to some other arbitrary limit. From: Chris Wright <chrisw@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29Add audit uid to netlink credentialsSerge Hallyn
Most audit control messages are sent over netlink.In order to properly log the identity of the sender of audit control messages, we would like to add the loginuid to the netlink_creds structure, as per the attached patch. Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29audit: update pointer to userspace tools, remove emacs mode tags
2005-04-29[AUDIT] Avoid using %*.*s format strings.Peter Martuccelli
They don't seem to work correctly (investigation ongoing), but we don't actually need to do it anyway. Patch from Peter Martuccelli <peterm@redhat.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29[AUDIT] Fix signedness of 'serial' in various routines.Steve Grubb
Attached is a patch that corrects a signed/unsigned warning. I also noticed that we needlessly init serial to 0. That only needs to occur if the kernel was compiled without the audit system. -Steve Grubb Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29audit_log_untrustedstring() warning fixAndrew Morton
kernel/audit.c: In function `audit_log_untrustedstring': kernel/audit.c:736: warning: comparison is always false due to limited range of data type Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-29AUDIT: Avoid log pollution by untrusted strings.
We log strings from userspace, such as arguments to open(). These could be formatted to contain \n followed by fake audit log entries. Provide a function for logging such strings, which gives a hex dump when the string contains anything but basic printable ASCII characters. Use it for logging filenames. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!