From: "Miloslav Trmač" <mitr@redhat.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-audit <linux-audit@redhat.com>,
viro@zeniv.linux.org.uk,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings
Date: Thu, 11 Sep 2008 16:43:19 +0200 [thread overview]
Message-ID: <1221144199.3033.47.camel@amilo> (raw)
In-Reply-To: <1221143113.2992.9.camel@localhost.localdomain>
Thanks for the review.
Eric Paris píše v Čt 11. 09. 2008 v 10:25 -0400:
> On Thu, 2008-09-11 at 00:23 +0200, Miloslav Trmač wrote:
> > This patch modifies audit_log_n_untrustedstring() to only log the data
> > before the first NUL byte, if any.
>
> I'm going to have to say NAK on this patch.
>
> It's still not right looking at the other user,
> audit_log_single_execve_arg(). An execve arg with a NULL could loose
> the stuff after the NULL (not break the record like audit_tty) since the
> execve uses %s rather than calling trusted string.
execve() arguments are NUL-terminated strings:
audit_log_single_execve_arg() starts with
len_left = len = strnlen_user(p, MAX_ARG_STRLEN) - 1;
and the two cycles handle chunks in the first "len" bytes of "p".
audit_log_single_execve_arg() never touches any bytes after the first
NUL.
So, when audit_log_single_execve_arg() calls
audit_string_contains_control(buf, to_send), strlen(buf) == to_send and
the patch does not change anything.
> How about we change the meaning of audit_string_contains_control()
> return values? If it returns positive that is the number of bytes in a
> legitimate string up to the first null. -1 means it is hex.
That is possible, although the return value convention is somewhat
complex. Anyway, no change to the semantics of
audit_string_contains_control() is necessary for execve() argument
logging.
Mirek
WARNING: multiple messages have this Message-ID (diff)
From: "Miloslav Trmač" <mitr@redhat.com>
To: Eric Paris <eparis@redhat.com>
Cc: viro@zeniv.linux.org.uk, linux-audit <linux-audit@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings
Date: Thu, 11 Sep 2008 16:43:19 +0200 [thread overview]
Message-ID: <1221144199.3033.47.camel@amilo> (raw)
In-Reply-To: <1221143113.2992.9.camel@localhost.localdomain>
Thanks for the review.
Eric Paris píše v Čt 11. 09. 2008 v 10:25 -0400:
> On Thu, 2008-09-11 at 00:23 +0200, Miloslav Trmač wrote:
> > This patch modifies audit_log_n_untrustedstring() to only log the data
> > before the first NUL byte, if any.
>
> I'm going to have to say NAK on this patch.
>
> It's still not right looking at the other user,
> audit_log_single_execve_arg(). An execve arg with a NULL could loose
> the stuff after the NULL (not break the record like audit_tty) since the
> execve uses %s rather than calling trusted string.
execve() arguments are NUL-terminated strings:
audit_log_single_execve_arg() starts with
len_left = len = strnlen_user(p, MAX_ARG_STRLEN) - 1;
and the two cycles handle chunks in the first "len" bytes of "p".
audit_log_single_execve_arg() never touches any bytes after the first
NUL.
So, when audit_log_single_execve_arg() calls
audit_string_contains_control(buf, to_send), strlen(buf) == to_send and
the patch does not change anything.
> How about we change the meaning of audit_string_contains_control()
> return values? If it returns positive that is the number of bytes in a
> legitimate string up to the first null. -1 means it is hex.
That is possible, although the return value convention is somewhat
complex. Anyway, no change to the semantics of
audit_string_contains_control() is necessary for execve() argument
logging.
Mirek
next prev parent reply other threads:[~2008-09-11 14:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 22:23 [PATCH 1/2] audit: fix NUL handling in untrusted strings Miloslav Trmač
2008-09-11 14:25 ` Eric Paris
2008-09-11 14:25 ` Eric Paris
2008-09-11 14:43 ` Miloslav Trmač [this message]
2008-09-11 14:43 ` Miloslav Trmač
2008-09-11 17:30 ` John Dennis
2008-09-11 18:10 ` Miloslav Trmač
2008-09-11 18:10 ` Miloslav Trmač
2008-09-11 18:15 ` Miloslav Trmač
2008-09-11 19:08 ` Steve Grubb
2008-09-11 19:08 ` Steve Grubb
2008-09-11 19:19 ` John Dennis
2008-09-11 19:12 ` John Dennis
2008-09-11 19:27 ` Miloslav Trmač
2008-09-11 19:27 ` Miloslav Trmač
2008-09-11 19:47 ` John Dennis
2008-09-11 20:03 ` Miloslav Trmač
2008-09-11 20:03 ` Miloslav Trmač
2008-09-11 19:14 ` Andrew Morton
2008-09-11 19:14 ` Andrew Morton
2008-09-11 19:37 ` Miloslav Trmač
2008-09-11 19:37 ` 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=1221144199.3033.47.camel@amilo \
--to=mitr@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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.