From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Paris <eparis@redhat.com>
Cc: mitr@redhat.com, linux-kernel@vger.kernel.org,
linux-audit@redhat.com, viro@zeniv.linux.org.uk
Subject: Re: [PATCH] Audit: fix handling of 'strings' with NULL characters
Date: Thu, 11 Sep 2008 17:09:20 -0700 [thread overview]
Message-ID: <20080911170920.e88e7bc5.akpm@linux-foundation.org> (raw)
In-Reply-To: <1221169719.2952.14.camel@localhost.localdomain>
On Thu, 11 Sep 2008 17:48:39 -0400
Eric Paris <eparis@redhat.com> wrote:
> currently audit_log_n_untrustedstring() uses
> audit_string_contains_control() to check if the 'string' has any control
> characters. If the 'string' has an embedded NULL
> audit_string_contains_control() will return that the data has no control
> characters and will then pass the string to audit_log_n_string with the
> total length, not the length up to the first NULL. audit_log_n_string
> does a memcpy of the entire length and so the actual audit record
> emitted may then contain a NULL and then whatever random memory is after
> the NULL.
>
> Since we want to log the entire octet stream (if we can't trust the data
> to be a string we can't trust that a NULL isn't actually a part of it)
> we should just consider NULL as a control character. If the caller is
> certain they want to stop at the first NULL they should be using
> audit_log_untrustedstring.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> ---
>
> Miloslav, this is also going to take care of nulls in the TTY_AUDIT_USER
> message from userspace. Is it going to be common to have control
> characters on that code path as well? Do you want to change
> audit_receive_msg() to also use the hex encoding directly instead of the
> _n_untrustedstring interface?
OK, I am now officially confused about the relationship between this
patch, Miloslav's two patches and 2.6.27/2.6.26/2.6.25.
Think I'll go into hiding for a while - please wake us up when it's all
sorted out.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Paris <eparis@redhat.com>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, jdennis@redhat.com, mitr@redhat.com,
sgrubb@redhat.com
Subject: Re: [PATCH] Audit: fix handling of 'strings' with NULL characters
Date: Thu, 11 Sep 2008 17:09:20 -0700 [thread overview]
Message-ID: <20080911170920.e88e7bc5.akpm@linux-foundation.org> (raw)
In-Reply-To: <1221169719.2952.14.camel@localhost.localdomain>
On Thu, 11 Sep 2008 17:48:39 -0400
Eric Paris <eparis@redhat.com> wrote:
> currently audit_log_n_untrustedstring() uses
> audit_string_contains_control() to check if the 'string' has any control
> characters. If the 'string' has an embedded NULL
> audit_string_contains_control() will return that the data has no control
> characters and will then pass the string to audit_log_n_string with the
> total length, not the length up to the first NULL. audit_log_n_string
> does a memcpy of the entire length and so the actual audit record
> emitted may then contain a NULL and then whatever random memory is after
> the NULL.
>
> Since we want to log the entire octet stream (if we can't trust the data
> to be a string we can't trust that a NULL isn't actually a part of it)
> we should just consider NULL as a control character. If the caller is
> certain they want to stop at the first NULL they should be using
> audit_log_untrustedstring.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> ---
>
> Miloslav, this is also going to take care of nulls in the TTY_AUDIT_USER
> message from userspace. Is it going to be common to have control
> characters on that code path as well? Do you want to change
> audit_receive_msg() to also use the hex encoding directly instead of the
> _n_untrustedstring interface?
OK, I am now officially confused about the relationship between this
patch, Miloslav's two patches and 2.6.27/2.6.26/2.6.25.
Think I'll go into hiding for a while - please wake us up when it's all
sorted out.
next prev parent reply other threads:[~2008-09-12 0:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-11 21:48 [PATCH] Audit: fix handling of 'strings' with NULL characters Eric Paris
2008-09-11 21:48 ` Eric Paris
2008-09-12 0:09 ` Andrew Morton [this message]
2008-09-12 0:09 ` Andrew Morton
2008-09-12 20:03 ` Miloslav Trmač
2008-09-12 20:03 ` Miloslav Trmač
2008-09-12 19:59 ` [PATCH] Audit: Ignore terminating NUL in AUDIT_USER_TTY messages Miloslav Trmač
2008-09-12 19:59 ` Miloslav Trmač
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080911170920.e88e7bc5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mitr@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.