On 02/10/2017 06:08 PM, Kees Cook wrote:
On Fri, Feb 10, 2017 at 4:01 PM, Tyler Hicks
<tyhicks(a)canonical.com> wrote:
> On 02/07/2017 06:33 PM, Kees Cook wrote:
>> This adds to UAPI, so it'd be good to think for a moment about how
>> this would work on older kernels: right now, if someone tried to use
>> this RET_LOG on an old kernel, it'll get treated like RET_KILL. Is
>> this sane?
>
> It is not sane for userspace code to blindly attempt to use a new
> feature on an old kernel. One of the main motivations of the
> actions_avail sysctl is to allow userspace to be smart about what the
> current kernel supports.
Yeah, agreed. I mean, userspace could also build a little test
program, toss in RET_LOG, run it and see if it get SIGSYS. But that's
so much more pain that checking in /proc.
> I'll be adding logic (requested by Paul) to libseccomp that checks this
> sysctl when SECOMP_RET_LOG is attempted to be used. Programs that don't
> use libseccomp will have to do something similar.
Excellent, I had been meaning to ask if you'd chatted with Paul at
all, since this is an API addition for libseccomp.
We talked through some of it after the initial PR that I submitted to
libseccomp:
https://github.com/seccomp/libseccomp/pull/64
I'll be updating that as we get closer to a land-able set of kernel patches.
Speaking of which, can you CC linux-api@ on the next version too?
Yes, good idea!
Tyler