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 5C6DF138819 for ; Tue, 10 Dec 2013 19:40:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04B66E0BDF; Tue, 10 Dec 2013 19:40:36 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BF7BEE0B52 for ; Tue, 10 Dec 2013 19:40:34 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id eo20so3043407lab.14 for ; Tue, 10 Dec 2013 11:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ZdMxeLIrgFZTAnPx4g/xM6rzpf2AIpNFgPHTQbz0e/g=; b=z6gdeED5zQloM13ExAWIam9AmE1WEO/kjI/sPRbbMTh96ETJftajmq6xP8tX0uLdwV yZSpQI6iYuFpdOzeGVT2zioTPhDXY+J0kqSdISXxOaIxzH56o5uhUFDB6c2CkOm9KPQI nKeJ3bAgmIlhHFOUn69XVGEfZUGx5DmXK8JsbSyJGWdwaN7m+GfKwxriqZ1+GMNNIOlk w5hrQciitLzNY/w6UiuZFti8es2w530VZ02emzadfPpXizU4WVFRwMXhfoZPd6R5AhFf FhGYFNs20p7MaGQ2/hrix5MzBNU4u4eRTbx1h514HA7vt3At3oBhnFqbrHS+m7eS7ZT9 d/kw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.152.234.37 with SMTP id ub5mr6265008lac.51.1386704433175; Tue, 10 Dec 2013 11:40:33 -0800 (PST) Received: by 10.114.77.10 with HTTP; Tue, 10 Dec 2013 11:40:33 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Dec 2013 13:40:33 -0600 Message-ID: Subject: Re: [gentoo-user] Re: How to grant a CAP_NET_RAW capability to user? From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: cc7b860c-79dc-4e41-9b4b-7d8848d75664 X-Archives-Hash: 51ecc24d421887d669bfbff742196b25 On Tue, Dec 10, 2013 at 12:56 PM, Grant Edwards wrote: > On 2013-12-10, Canek Pel??ez Vald??s wrote: > >>> How do you grant a capability (e.g. CAP_NET_RAW) to a user? > >> From man:capabilities(7): "Capabilities are a per-thread attribute." >> >> I don't think you can grant any capability to a user. > > I've found some indications that you can. Various references to > PAM_CAP imply that I should be able to do what I want. From > http://blog.siphos.be/2013/05/restricting-and-granting-capabilities/: > > You can also grant capabilities to users selectively, using > pam_cap.so (the Capabilities Pluggable Authentication Module). I think my proposal could be implemented using PAM, but it would be the same, I suppose. > But the example provided only shows how to grant capabilities to a > user that can then be inherited by files which must also have that > same capability enabled. That's not quite what I want to do (and it > doesn't seem to work). The restriction to files already having the capability is for security reasons, obviously: if a user has certain capability, and she forgets to change the others access to some executable, then anyone has the capability (if I understand correctly). > There are two reasons that granting the capability to the executable > isn't feasible: > > 1) Some of the programs are written in Python, and I don't want to > grant the capability to all Python programs by setting the > capability on /usr/bin/python. Again, create an executable with CAP_SETPCAP that executes the Python programs and sets the capabilities for the running program. > 2) Some of the programs are ELF executables (compiled C programs) > that are under developement and are being continuously re-built > and re-run. If I have to do a "sudo setcap" everytime I > compile/run a program, then I might as well just do "sudo > " the way I do now. You can create (once) an executable with CAP_SETFCAP, which your build system calls automatically every time you recompile and that sets the CAP_NET_RAW capability for the resulting executable. Not very secure anyway, but I think it could work. >> A workaround for what you want is to write a little executable that >> only execvp's bash (or whatever shell you use), grant that executable >> CAP_NET_RAW, and then set it as default shell with usermod. > > I thought about that, but that seems fragile. > I supposed I could set the capability on /bin/bash with +p instead of > +ep, then it should only take effect for users who have the capability > enabled (though I haven't been able to get that to work yet). I think the problem is that you want to use capabilities in a way that they are not designed for: you don't set capabilities at development time, you do it at deployment time. I would develop in a container or a VM until the program is ready and then deploy it with capabilities enabled. Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico