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 B7A1813827E for ; Tue, 10 Dec 2013 20:08:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9F92AE0B0B; Tue, 10 Dec 2013 20:07:57 +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 6F880E0A9B for ; Tue, 10 Dec 2013 20:07:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 92CFB33F99E for ; Tue, 10 Dec 2013 20:07:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5.5 tests=[AWL=-2.267, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCKHVcnoGBxh for ; Tue, 10 Dec 2013 20:07:49 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 76A3E33F898 for ; Tue, 10 Dec 2013 20:07:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VqTap-0004j5-4M for gentoo-user@gentoo.org; Tue, 10 Dec 2013 21:07:43 +0100 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Dec 2013 21:07:43 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Dec 2013 21:07:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: How to grant a CAP_NET_RAW capability to user? Date: Tue, 10 Dec 2013 20:07:19 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dsl.comtrol.com User-Agent: slrn/1.0.1 (Linux) 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 X-Archives-Salt: dba51dac-77a4-47e6-8d98-a48e92f7bf7f X-Archives-Hash: 734063562a65a521a9ef5a268245d2b9 On 2013-12-10, Canek Pel??ez Vald??s wrote: >> 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). No, that's not how it works. You can use pam_cap to grant an inheritable capability to a user, but it can only be used by files that also have the capability to inherit that capability. There are basically two ways you can set a capability on a file: the file can have the capability regardless of the user, or the file can have the capability only if it can be inherited from the user. If you grant a capability to a file using "setcap cap_whatever+ei myprog" then it's only effective for users that also have cap_whatever enabled in /etc/security/capability.conf If you grant a capability to a file using "setcap cap_whatever+ep", then it's available to all users. > Again, create an executable with CAP_SETPCAP that executes the Python > programs and sets the capabilities for the running program. [...] > 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. It's a lot simpler to just continue using sudo to run the programs. >>> 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. That wouldn't help. I've figured out how to give bash CAP_NET_RAW capabilities for a specified user, but it still requires that executables have the same capability set. >> 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). That doesn't work either. Bash gets the privledges in question but they aren't inherited by programs invoked by bash unless they have already had those capabilities set. > I think the problem is that you want to use capabilities in a way that > they are not designed for: Apparently so. > 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. No, that's not the problem. The problem is that the whole system is designed to assign capabilities to _files_, and I want to assign a capablity to a user. -- Grant Edwards grant.b.edwards Yow! BELA LUGOSI is my at co-pilot ... gmail.com