Date:	Mon, 26 Mar 2012 10:02:34 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	linux-kernel@...r.kernel.org, Eric Paris <eparis@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] audit: always report seccomp violations

On Mon, Mar 26, 2012 at 9:59 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 3/26/2012 8:56 AM, Kees Cook wrote:
>> On Sun, Mar 25, 2012 at 11:47 AM, Casey Schaufler
>> <casey@...aufler-ca.com> wrote:
>>> On 3/23/2012 4:32 PM, Kees Cook wrote:
>>>> When a program violates its own seccomp rules, that is a pretty dire
>>>> situation, and the audit message should always be reported (not just
>>>> when there is already a rule active for the process).
>>> Hmm. If the program is never going to violate its own
>>> seccomp rules it seems sort of silly to have them in the
>>> first place, doesn't it? Oh, I know that the expectation
>>> of seccomp is that the application would only try something
>>> you've disallowed if it gets compromised. Problem is that
>> Well, either compromised or doing something new (e.g. a library in the
>> code has changed).
>>
>>> Modern Programmers tend to rely very heavily on the opaque
>>> behavior of APIs that they don't understand nor particularly
>>> care if they understand. When assumptions are made about the
>>> behavior of the API code, and the API code changes, as
>>> occurs with amazing frequency on today's mobile devices,
>>> there are going to be surprises. I would wager that the
>>> modern frequency of API changes will result in this behavior
>>> being very unpopular.
>> You seem to be advocating for my patch -- instead of the program
>> "silently" getting killed, now there will be notification. A seccomp
>> failure is extremely uncommon; much less common that core dumps. This
>> is why it should always be reported -- it is uncommon and important to
>> notice.
>
> Silence is golden. The situation that I am concerned with is one where
> a library changes and a program preforms an action that results in a
> violation. The application runtime environment notices the applications
> demise and restarts it, resulting in a repeat of the violation.
>
> In a classic computer environment you would want the log filled with
> notifications so that the user could do something about it. On a
> phone, settop box, TV set or seatback entertainment system logging is
> evil. No one who has any business seeing a log message has any desire
> to see one. It does not matter how important the log message might be.
>
> It's getting harder and harder to have rational error handling at the
> OS level as application environments move to higher levels and greater
> abstraction. Because seccomp is an OS interface level facility there
> are going to be many cases where it fails to align with the intent of
> its highly abstracted users. When it does, the programmers are not
> going to look at the OS level logs, they are going to look at the API
> definitions and such.
>
> In the end I am opposed to any logging that can't be turned off. There
> is enough difference in environments and expectations that you can't
> say that something should always be reported. I am not saying that I
> approve of this situation, but it is clear that most modern application
> developers want to hear as little from the OS as possible. Even in
> cases where they should be paying attention.

Handling logging output is up to the system owner. Already all
segfaults are reported to dmesg. Seccomp violation is a much less
common case, so I think the benefit outweighs the potential for
"clutter". If a system owner wants to ignore klog, they can go ahead
and do so. :)

-Kees

-- 
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists