[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKY6GtSrUeP7Rgs70HHaFudjw29QOAbfhyS=Jx=2VOyJw@mail.gmail.com>
Date: Fri, 10 Feb 2017 16:08:37 -0800
From: Kees Cook <keescook@...omium.org>
To: Tyler Hicks <tyhicks@...onical.com>
Cc: Paul Moore <paul@...l-moore.com>, Eric Paris <eparis@...hat.com>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>, linux-audit@...hat.com,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] seccomp: Create an action to log before allowing
On Fri, Feb 10, 2017 at 4:01 PM, Tyler Hicks <tyhicks@...onical.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. Speaking of which,
can you CC linux-api@ on the next version too?
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists