public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2008-09-11 14:44 UTC|newest]

Thread overview: 10+ 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:43   ` Miloslav Trmač [this message]
     [not found]   ` <48C955C8.2000602@redhat.com>
2008-09-11 18:10     ` Miloslav Trmač
2008-09-11 18:15       ` Miloslav Trmač
2008-09-11 19:08       ` Steve Grubb
     [not found]       ` <48C96D90.70608@redhat.com>
2008-09-11 19:27         ` Miloslav Trmač
     [not found]           ` <48C975D5.3020603@redhat.com>
2008-09-11 20:03             ` Miloslav Trmač
2008-09-11 19:14 ` Andrew Morton
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox