From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FYtap-0000ow-4c for garchives@archives.gentoo.org; Wed, 26 Apr 2006 23:38:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k3QNa7SK031742; Wed, 26 Apr 2006 23:36:07 GMT Received: from fuse.inversepath.com (fuse.inversepath.com [69.60.119.224]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k3QNa6gm019022 for ; Wed, 26 Apr 2006 23:36:06 GMT Received: from fuse.inversepath.com (localhost [127.0.0.1]) by fuse.inversepath.com (8.13.6/8.13.6) with ESMTP id k3QNa5Mg029039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 23:36:06 GMT Received: (from lcars@localhost) by fuse.inversepath.com (8.13.6/8.13.6/Submit) id k3QNa5iX022143; Wed, 26 Apr 2006 23:36:05 GMT Date: Wed, 26 Apr 2006 23:36:05 +0000 From: Andrea Barisani To: gentoo-security@lists.gentoo.org Cc: gentoo-hardened@lists.gentoo.org, Niels Provos Subject: Re: [gentoo-security] Re: [gentoo-hardened] Systrace resurrection Message-ID: <20060426233605.GK29037@fuse.inversepath.com> Mail-Followup-To: gentoo-security@lists.gentoo.org, gentoo-hardened@lists.gentoo.org, Niels Provos References: <20060426134440.GJ29037@fuse.inversepath.com> <444FA171.5024.55CFB9CB@pageexec.freemail.hu> <444F8A89.7090106@gentoo.org> <20060426151925.GQ29037@fuse.inversepath.com> <444FA6D7.6070602@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444FA6D7.6070602@gentoo.org> X-GPG-Key: 0x864C9B9E X-GPG-Fingerprint: 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E User-Agent: Mutt/1.5.11 X-Archives-Salt: 878ebdd8-871d-4aeb-a434-40002a545c8f X-Archives-Hash: 8ca5f8b9995b552a668cf15479c8a343 On Wed, Apr 26, 2006 at 12:59:03PM -0400, Joshua Brindle wrote: > Well, systrace is path based so you can apply all those arguments > directly. I don't understand what you mean by systrace is not MAC, what > is it? It has a policy, it enforces access control. I guess choosing to > run the app under it directly makes it discretionary. It still has all > the issues that my blog such as ambiguous paths, problems in shared > directories, etc. Did you bother checking how systrace checks/applies the path? (the tone isn't accusatory here, I didn't do it yet myself, but still we can't flame it without knowing its implementation, this is not as easy to evaluate as you try to put it design-wise). Admitedly you don't know much about systrace implementation, would you kindly check into it and see how it *really* works before judging it? Not saying that this should make you change your mind but it would probably be best and it would allow a much more constructive feedback. Neils, any comments about this? > What you are doing in essence is making all binaries setuid by allowing > privilege escalation. Think about it, setuid tells the linux kernel to "all binaries" ? I never said that I'd apply this to all binaries, systrace is discretionary so to speak... > change the uid when this app is run, so you "remove" the setuid bit and > let systrace escalate the capabilities by bypassing the kernel, this is > not different from just having the binary be setuid and then only > allowing whichever caps it needs and is more dangerous since there is a > single layer controlling capabilities for an attack vector. > systrace "becomes" a kernel feature, systrace "bypassing" the kernel makes no sense to me, but I guess this is a semantic issue... This is just moving the all-permissive setuid concept (which I might say can be arguably a kinda broken/insecure thing) to a syscall acl framework. > Neither grsecurity nor SELinux allow any kind of bypass of standard > linux kernel permissions. They cannot lower the security level of the > system whereas systrace can by granting capabilities that processes > would not have had otherwise. > Systrace can lower the security level of the system if *you* configure it to do so as *root* (which could do that anyway), this is just shifting the sec model from 'setuid lets the process run as root but we "jail" it with MAC' to "we remove setuid and we selectively allow kernel_side what it can do". Unless you are really dumb in defining policies I can't see how this could be heavily mis-used / compromised. Neils, Method: all feedback is welcome. Cheers -- Andrea Barisani .*. Gentoo Linux Infrastructure Developer V ( ) PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc ( ) 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E ^^_^^ "Pluralitas non est ponenda sine necessitate" -- gentoo-hardened@gentoo.org mailing list