[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110815185114.GA20115@openwall.com>
Date: Mon, 15 Aug 2011 22:51:14 +0400
From: Solar Designer <solar@...nwall.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Andi Kleen <andi@...stfloor.org>, Vasiliy Kulikov <segoon@...nwall.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, James Morris <jmorris@...ei.org>,
kernel-hardening@...ts.openwall.com, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
Will Drewry <wad@...omium.org>
Subject: Re: [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls
On Sun, Aug 14, 2011 at 07:48:51AM -0700, H. Peter Anvin wrote:
> i386 vs x86-64 vs x32 is just one of many axes along which syscalls can be restricted (and for that matter, one axis if backward compatibility), and it does not make sense to burden the code with ad hoc filters. Designing a general filter facility which can be used to restrict any container to the subset of system calls it actually needs would make more sense, no?
I agree with you that i386 vs x86-64 vs x32 is one axis and syscall
number is another axis. I'd like to be able to setup restrictions on
both. So I support both Vasiliy's patch (a future revision of it; his
RFC posting was just to get the discussion started) and Will's seccomp
patch (maybe with further changes for inheritance on fork and execve).
On specific systems I (co-)administer, I have immediate need for the 32-
vs. 64-bit restrictions. These are easy to put to use, with changes
only to the kernel (Vasiliy's patch) and to the vzctl program (read a
setting from a per-container config file, make the right prctl() call).
Per-syscall restrictions are also useful, but primarily at a different
level - I'd expect them to be used in specific programs, such as Chrome
and vsftpd. Those programs may also want to limit themselves to a
certain type of syscalls (that is, on the i386 vs x86-64 vs x32 axis),
thereby making use of both features at once. Or they might even have to
do that, depending on how we implement the syscall restrictions.
Per your suggestion, if I understand correctly, any task that wants to
restrict itself on the i386 vs x86-64 vs x32 axis will have TIF_SECCOMP
set and will incur calls into __secure_computing(). This is unnecessary
overhead for the case when we have a restriction over this axis only,
without per-syscall restrictions. Vasiliy's patch avoids such overhead.
Alexander
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.
