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

On Mon, Mar 26, 2012 at 10:02 AM, Kees Cook <keescook@...omium.org> wrote:
> 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. :)

Eric, do you have thoughts on this? I'd really like to see seccomp
failures regardless of audit daemon state.

-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