On 2016-01-26 13:27, Andy Lutomirski wrote:
On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
On 2016-01-26 12:15, Serge Hallyn wrote:
Quoting Josh Boyer (jwboyer@xxxxxxxxxxxxxxxxx):
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
Kees Cook <keescook@xxxxxxxxxxxx> writes:
On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
Kees Cook <keescook@xxxxxxxxxxxx> writes:
Well, I don't know about less weird, but it would leave a unneeded
hole in the permission checks.
To be clear the current patch has my:
Nacked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
The code is buggy, and poorly thought through. Your lack of interest
in
fixing the bugs in your patch is distressing.
I'm not sure where you see me having a "lack of interest". The
existing cap-checking sysctls have a corner-case bug, which is
orthogonal to this change.
That certainly doesn't sound like you have any plans to change anything
there.
So broken code, not willing to fix. No. We are not merging this
sysctl.
I think you're jumping to conclusions. :)
I think I am the maintainer.
What you are proposing is very much something that is only of interst to
people who are not using user namespaces. It is fatally flawed as
a way to avoid new attack surfaces for people who don't care as the
sysctl leaves user namespaces enabled by default. It is fatally flawed
as remediation to recommend to people to change if a new user namespace
related but is discovered. Any running process that happens to be
created while user namespace creation was enabled will continue to
exist. Effectively a reboot will be required as part of a mitigation.
Many sysadmins will get that wrong.
I can't possibly see your sysctl as proposed achieving it's goals. A
person has to be entirely too aware of subtlety and nuance to use it
effectively.
What you're saying is true for the "oh crap" case of a new userns
related CVE being found. However, there is the case where sysadmins
know for a fact that a set of machines should not allow user
namespaces to be enabled. Currently they have 2 choices, 1) use their
Hi - can you give a specific example of this? (Where users really should
not be able to use them - not where they might not need them) I think
it'll help the discussion tremendously. Because so far the only good
arguments I've seen have been about actual bugs in the user namespaces,
which would not warrant a designed-in permanent disable switch. If
there are good use cases where such a disable switch will always be
needed (and compiling out can't satisfy) that'd be helpful.
In general, if a particular daemon provides a network service and does not
use user namespaces for sand-boxing, it should not be allowed to use user
namespaces, because those then become something else to potentially land an
exploit through. ntpd, postfix, and most other regularly used network
servers fall into this category.
seccomp handles this issue quite nicely.
seccomp is a pain to set up given current tooling, and isn't supported
by most server software. Unless there's some tool out there to hook
arbitrary seccomp filters into an arbitrary program, then this isn't an
option for most people.
If you're hosting a shared system providing terminal server like usage where
the users actually have shell access, then they probably should not be able
to use user namespaces on the server.
Au contraire. If they have user ns access, then can sandbox their own programs.
I should clarify, by 'terminal server like usage' I meant thin client
setups, not Sun Ray or Windows style terminal servers. IOW, a file
server that provides a few extra services (DHCP, TFTP and similar) and
only allows shell access so users can move around their own files
directly on the server.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
