[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKNKQvDk_V3bSa6Bp18VTMJkdixk9tUOVGNWaxjsnfqug@mail.gmail.com>
Date: Sat, 28 Mar 2015 06:03:05 -0700
From: Kees Cook <keescook@...omium.org>
To: felix-linuxkernel@...e.de
Cc: LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>
Subject: Re: security problem with seccomp-filter
On Thu, Mar 26, 2015 at 11:39 PM, Richard Weinberger
<richard.weinberger@...il.com> wrote:
> Cc'ing seccomp folks.
>
> On Fri, Mar 27, 2015 at 6:56 AM, Felix von Leitner
> <felix-linuxkernel@...e.de> wrote:
>> Hi,
>>
>> I have had some great success with seccomp-filter a while ago, so I
>> decided to use it to add some defense in depth to a ping program I wrote.
>>
>> The premise is, like for all ping programs I assume, that it starts
>> setuid root, gets a raw socket, drops privileges, parses the command
>> line, potentially does a DNS lookup, and then it sends and receives
>> packets, using gettimeofday and poll.
>>
>> So I added a seccomp filter that allows this. But where do you put it?
>> Ideally you'd want the filter installed right away after dropping
>> privileges, so the command line parsing and the DNS routines are
>> secured, too. But then you'd allow unnecessary attack surface (why allow
>> open after the DNS routines are done parsing /etc/resolv.conf, for
>> example?).
>>
>> The documentation says you can add more than one seccomp filter, just
>> call prctl multiple times and allow prctl initially.
>>
>> So that's what I did.
>>
>> But when I added the secondary filters (which would blacklist open and
>> setsockopt), and for double checking tried installing the last one twice
>> (after the last one was supposed to blacklist prctl), to my surprise
>> my attempt did not lead to process termination but to a success return
>> value.
>>
>> I think this is a serious security breach. Maybe I am the first one to
>> attempt to install multiple seccomp filters in the same process?
>> The observed behavior is consistent with only the first filter being
>> consulted.
>>
>> I'm using stock kernel 3.19 for what it's worth.
What you're describing should work correctly (it's part of the
regression test suite we use). So, given that, I'd love to get to the
bottom of what you're seeing. Do you have a URL to your code? What
architecture are you running on?
Thanks!
-Kees
--
Kees Cook
Chrome OS 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