24 May, 2005

1 commit


22 May, 2005

1 commit

  • Move audit_serial() into audit.c and use it to generate serial numbers
    on messages even when there is no audit context from syscall auditing.
    This allows us to disambiguate audit records when more than one is
    generated in the same millisecond.

    Based on a patch by Steve Grubb after he observed the problem.

    Signed-off-by: David Woodhouse

    David Woodhouse
     

21 May, 2005

2 commits


19 May, 2005

3 commits

  • The limit on the number of outstanding audit messages was inadvertently
    removed with the switch to queuing skbs directly for sending by a kernel
    thread. Put it back again.

    Signed-off-by: David Woodhouse

    David Woodhouse
     
  • netlink_unicast() will attempt to reallocate and will free messages if
    the socket's rcvbuf limit is reached unless we give it an infinite
    timeout. So do that, from a kernel thread which is dedicated to spewing
    stuff up the netlink socket.

    Signed-off-by: David Woodhouse

    David Woodhouse
     
  • * If vsnprintf returns -1, it will mess up the sk buffer space accounting.
    This is fixed by not calling skb_put with bogus len values.

    * audit_log_hex was a loop that called audit_log_vformat with %02X for each
    character. This is very inefficient since conversion from unsigned character
    to Ascii representation is essentially masking, shifting, and byte lookups.
    Also, the length of the converted string is well known - it's twice the
    original. Fixed by rewriting the function.

    * audit_log_untrustedstring had no comments. This makes it hard for
    someone to understand what the string format will be.

    * audit_log_d_path was never fixed to use untrustedstring. This could mess
    up user space parsers. This was fixed to make a temp buffer, call d_path,
    and log temp buffer using untrustedstring.

    From: Steve Grubb
    Signed-off-by: David Woodhouse

    Steve Grubb
     

18 May, 2005

1 commit


14 May, 2005

3 commits

  • Der... if you use max_t it helps if you give it a type.

    Note to self: Always just apply the tested patches, don't try to port
    them by hand. You're not clever enough.

    Signed-off-by: David Woodhouse

    David Woodhouse
     
  • I'm going through the kernel code and have a patch that corrects
    several spelling errors in comments.

    From: Steve Grubb
    Signed-off-by: David Woodhouse

    Steve Grubb
     
  • This patch adds more messages types to the audit subsystem so that audit
    analysis is quicker, intuitive, and more useful.

    Signed-off-by: Steve Grubb
    ---
    I forgot one type in the big patch. I need to add one for user space
    originating SE Linux avc messages. This is used by dbus and nscd.

    -Steve
    ---
    Updated to 2.6.12-rc4-mm1.
    -dwmw2

    Signed-off-by: David Woodhouse

    Steve Grubb
     

13 May, 2005

1 commit


11 May, 2005

7 commits


06 May, 2005

5 commits

  • Signed-off-by: David Woodhouse

    David Woodhouse
     
  • Drop the use of a tmp buffer in the audit_buffer, and just buffer
    directly to the skb. All header data that was temporarily stored in
    the audit_buffer can now be stored directly in the netlink header in
    the skb. Resize skb as needed. This eliminates the extra copy (and
    the audit_log_move function which was responsible for copying).

    Signed-off-by: Chris Wright
    Signed-off-by: David Woodhouse

    Chris Wright
     
  • Introduce audit_expand and make the audit_buffer use a dynamic buffer
    which can be resized. When audit buffer is moved to skb it will not
    be fragmented across skb's, so we can eliminate the sklist in the
    audit_buffer. During audit_log_move, we simply copy the full buffer
    into a single skb, and then audit_log_drain sends it on.

    Signed-off-by: Chris Wright
    Signed-off-by: David Woodhouse

    Chris Wright
     
  • Signed-off-by: Chris Wright
    Signed-off-by: David Woodhouse

    Chris Wright
     
  • shutdown credential information. It creates a new message type
    AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the
    shutdown.

    It requires the placement of a hook function that gathers the information. The
    hook is after the DAC & MAC checks and before the function returns. Racing
    threads could overwrite the uid & pid - but they would have to be root and
    have policy that allows signalling the audit daemon. That should be a
    manageable risk.

    The userspace component will be released later in audit 0.7.2. When it
    receives the TERM signal, it queries the kernel for shutdown information.
    When it receives it, it writes the message and exits. The message looks
    like this:

    type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650
    uid=525, auditd pid=1685

    Signed-off-by: Steve Grubb
    Signed-off-by: David Woodhouse

    Steve Grubb
     

05 May, 2005

1 commit


04 May, 2005

1 commit

  • 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
    Signed-off-by: David S. Miller

    Herbert Xu
     

03 May, 2005

1 commit

  • 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
    Signed-off-by: David Woodhouse

    Chris Wright
     

30 Apr, 2005

1 commit


29 Apr, 2005

6 commits


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds