Messages in this thread | | | Date | Mon, 26 Mar 2012 10:02:34 -0700 | Subject | Re: [PATCH] audit: always report seccomp violations | From | Kees Cook <> |
| |
On Mon, Mar 26, 2012 at 9:59 AM, Casey Schaufler <casey@schaufler-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@schaufler-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
| |