linux-kernel - Re: [RFC] Make Yama pid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111123165549.GB3463@albatros>
Date:	Wed, 23 Nov 2011 20:55:50 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [RFC] Make Yama pid_ns aware

On Wed, Nov 23, 2011 at 14:49 +0000, Serge E. Hallyn wrote:
> Quoting Vasiliy Kulikov (segoon@...nwall.com):
> > Actually, what concerns me is not ptrace, but symlink/hardling
> > protection.  There is no interaction between namespaces in case of
> > containers via symlinks in the basic case.  In case of ptrace I don't
> > think the child ns may weaken the parent ns - child ns may not access
> > processes of the parent namespace and everything it may ptrace is
> > already inside of this ns.
> 
> Oh, yes.  If you're saying the symlink protection shouldn't be
> per-pidns, I agree it seems an odd fit.
> 
> How about a version of this patch leaving symlink protection
> out of pidns (maybe in user ns), and just putting ptrace
> protection per-pidns?

I don't think moving symlink/hardling from pid ns to user ns is a good
idea as user ns is not matured yet.  Also we (Openwall) want to use Yama
almost as-is in our RHEL6 and RHEL5-based kernels with OpenVZ support
which don't have user namespaces yet at all (yes, it is not a cause for
mainline decisions :-) ).

While user ns is not yet ready, I don't clearly see what is the division
of security policies among namespaces including user namespace.  I had
a view that all stuff related to processes (i.e. distinct processes in
several ways) belongs to pid ns, all net stuff to net ns, etc.  If we
differentiate user ns and pid ns, only strictly things handling pids
(like kill(2), procfs, ptrace(2), etc.) belong to pid ns and all other
process-related stuff (like credentials handling, these symlink/hardling
things, etc.) belong to user namespaces.

Can we probably leave them in pid ns for now and when user ns is matured
just move it from pid ns to user ns?  Is it possible without breaking
Yama's ABI (I think so)?

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/