From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1FB641386A5 for ; Sat, 26 Jan 2013 07:46:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2DB3321C019; Sat, 26 Jan 2013 07:46:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2037421C00D for ; Sat, 26 Jan 2013 07:46:13 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 32C4533DBC3 for ; Sat, 26 Jan 2013 07:46:12 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree Date: Sat, 26 Jan 2013 02:46:12 -0500 User-Agent: KMail/1.13.7 (Linux/3.7.1; KDE/4.6.5; x86_64; ; ) References: <201301251851.45021.vapier@gentoo.org> <1359159053.32487.4.camel@kanae> In-Reply-To: <1359159053.32487.4.camel@kanae> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3200250.UmJQPs55MG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201301260246.12861.vapier@gentoo.org> X-Archives-Salt: 353beb33-b90b-4d89-80d0-0c6ec6a7cf8b X-Archives-Hash: 7709e3f445809861d879dc21df30d599 --nextPart3200250.UmJQPs55MG Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: > It's not like libcap is a big dependency true, but not everyone needs this, nor can everyone leverage it (caps). it= 's=20 a linux-centric implementation and is dependent upon filesystem support bei= ng=20 available & enabled. that doesn't entirely justify making it a USE flag (since the code already = has=20 runtime fallback logic for when the fs doesn't support things), but since t= he=20 USE is low overhead and leverages logic that already has to be there, i hav= e=20 no problem keeping it. plus it defaults to on. > and it's not like this is an > attempt to make the system more secure by according just the privileges > needed for apps to work as intended, right ? mmm that's exactly what this is > If the USE flag must stay, how is it different that current caps USE > flag ? It applies and not just enables support but is that relevant to > the purpose at hand ? USE=3Dcaps is for apps to control their runtime privs (there's also package= s=20 which want to query things like coreutils, but let's ignore those). in ord= er=20 to grant themselves reduced privs, they have to start with them in the firs= t=20 place -- capabilities allows you to remove privs from yourself, not extend= =20 them. that's accomplished (classically & today) by having the program set*= id. =20 thus, when the program is run, it is (typically) launched as the root user= =20 which means they have the full capset. if the package supports USE=3Dcaps, then it means the program is intelligen= t=20 enough to know what capabilities it needs and so it can drop all of the res= t=20 before executing the main body of code. if it doesn't support USE=3Dcaps, = then=20 it either tries to do all the superuser stuff first and then drop its uid b= ack=20 down to the executing user's. if it can't do that, then it has to be super= =20 careful about everything it does. some packages (like openssh and Google=20 Chrome -- not great examples, but good enough) implement even more complica= ted=20 setups with privilege separation where there is IPC between a privileged=20 process and an unprivileged one. either way, obviously the more code you have, the harder it is to make sure= =20 you get it right (and history is littered with vulns where people didn't). = so=20 wouldn't it be nice if you could set the required capabilities on a binary = and=20 drop the set*id entirely ? that's what USE=3Dfilecaps gets us. now there = is no=20 time frame within which you can attack and gain elevated privileges -- the= =20 kernel will have the new program start off with the right capset from the v= ery=20 beginning. obviously i'm glossing over bugs where people can get get a program to do=20 things it shouldn't with the capset it didn't drop, but that scenario exist= s=20 regardless of set*id and USE=3Dcaps behavior. in the ideal world: - USE=3Dfilecaps so you start only with the caps you need - not be set*id at all - do all the things at the very beginning that require the elevated caps - support USE=3Dcaps so you can then drop all of your elevated caps - run like normal and process all user input as an example, let's look at ping. we give it set*id because people want t= o=20 be able to do something innocuous as `ping 192.168.0.1` w/out `sudo` first.= in=20 order to send ICMP_ECHO packets, it needs to create a SOCK_RAW socket which= =20 the kernel doesn't allow random users to create (otherwise they could gener= ate=20 arbitrary packets on the network). when USE=3D-cap, the first thing ping d= oes is=20 create the socket, then drop the root uid. when USE=3Dcap, the first thing= it=20 does is drop all of its permitted caps to the bare min what it needs in the= =20 future, and then sets the effective even lower. when it needs to open the= =20 socket, it sets the effective to what it needs, opens the socket, and then = sets=20 the effective lower again. rinse/repeat. at least, this is all my understanding of things. i could be completely=20 wrong, so feel free to correct something if you notice it. =2Dmike --nextPart3200250.UmJQPs55MG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRA4nEAAoJEEFjO5/oN/WB3SsQANHZBHeNOOobz9PWqHCAupnU /r2lNKka5Yc/dG5uKiNpkiaHEZD9thXIG9VSfPdL8jqCrn8VnKq8gt2OMCN5qstq R2Sxa04rN7LHQ8s62mY6BKfT2xTUxFiav2M8Rx8/b0mBJ81PFJ1uFnMy5KtCzi/y L7U7GXVSMiDI/FlUFsUMBcGeYR5mlODK5jR6Izdl3X1My+VosEThv9qEhQldy4pG gfcBVIFK/mB7jimDOu/LqOwrQFLOhDB1IrG/GvqG1ICozE+Z2d0KldbbiDBsV0Ff vLpdq7wG8bCpehqmw14DSb767uWHMQ0Df93UGtjvZHmumVWsUOZs6ZJ4pWKgue9a 6fBg+cLzB9iaLggF2vQg/5m2+zZL0LCs5pnOYtlYB2JSJRze3BEQlw8ql1MzWh9V 5YjnNIVh3VOHPO5psCpEsMIUovOIQr5DSaa/9d264Tqqzcxxqmy/aR7CPHAFUFi8 Q3dk95FbcS9OJ7mGgBq2bFQZK+0VTttWvLeU9oXjsKI5wM/VTHVN3/7+BwDZsy92 JJq5w1HqjPNvhQB+U2x0HiAzADkcmuKKQt8nNK9EdLOJ6uFyJGDoTrlJkyB6hJPQ GKxtdyf7+m9oWL4RD6TUsr9MQpXVRrumfQsJYpTJttpLmoSHVvqoc9NWGHvgUXl2 xqhmYb/l9UF+hpyKv7DO =dHxb -----END PGP SIGNATURE----- --nextPart3200250.UmJQPs55MG--