[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBED482.4050800@zytor.com>
Date: Thu, 24 May 2012 17:38:26 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Lutomirski <luto@....edu>
CC: James Morris <jmorris@...ei.org>, Will Drewry <wad@...omium.org>,
linux-kernel@...r.kernel.org, mcgrathr@...gle.com, indan@....nu,
netdev@...isplace.org, linux-security-module@...r.kernel.org,
kernel-hardening@...ts.openwall.com, mingo@...hat.com, oleg@...hat.com,
peterz@...radead.org, rdunlap@...otime.net, tglx@...utronix.de,
serge.hallyn@...onical.com, pmoore@...hat.com,
akpm@...ux-foundation.org, corbet@....net, markus@...omium.org,
coreyb@...ux.vnet.ibm.com, keescook@...omium.org,
viro@...iv.linux.org.uk
Subject: Re: [RFC PATCH 0/3] move the secure_computing call
On 05/24/2012 05:26 PM, Andrew Lutomirski wrote:
>
> Just to clarify: are you suggesting that, for now, the traced behavior
> should be:
>
> process -> seccomp -> ptrace -> kernel?
>
> If so, I think the man page or something should have a big fat warning
> that seccomp filters should *never* allow ptrace (even PTRACE_TRACEME)
> unless they fully understand the issue.
>
Yes, and yes.
> In any case, I think that the UML interaction is missing the point.
> UML will *emulate* the seccomp filter. If it chooses to use host
> seccomp filters for some business, that's its business.
I don't see why UML should have to emulate the seccomp filter. With the
proposed order, then it can simply use the seccomp filter provided by
the host. Furthermore, with this sequencing UML can actually *use*
seccomp to provide the simulation.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
