| 1 |
On Tue, Dec 10, 2013 at 12:56 PM, Grant Edwards |
| 2 |
<grant.b.edwards@×××××.com> wrote: |
| 3 |
> On 2013-12-10, Canek Pel??ez Vald??s <caneko@×××××.com> wrote: |
| 4 |
> |
| 5 |
>>> How do you grant a capability (e.g. CAP_NET_RAW) to a user? |
| 6 |
> |
| 7 |
>> From man:capabilities(7): "Capabilities are a per-thread attribute." |
| 8 |
>> |
| 9 |
>> I don't think you can grant any capability to a user. |
| 10 |
> |
| 11 |
> I've found some indications that you can. Various references to |
| 12 |
> PAM_CAP imply that I should be able to do what I want. From |
| 13 |
> http://blog.siphos.be/2013/05/restricting-and-granting-capabilities/: |
| 14 |
> |
| 15 |
> You can also grant capabilities to users selectively, using |
| 16 |
> pam_cap.so (the Capabilities Pluggable Authentication Module). |
| 17 |
|
| 18 |
I think my proposal could be implemented using PAM, but it would be |
| 19 |
the same, I suppose. |
| 20 |
|
| 21 |
> But the example provided only shows how to grant capabilities to a |
| 22 |
> user that can then be inherited by files which must also have that |
| 23 |
> same capability enabled. That's not quite what I want to do (and it |
| 24 |
> doesn't seem to work). |
| 25 |
|
| 26 |
The restriction to files already having the capability is for security |
| 27 |
reasons, obviously: if a user has certain capability, and she forgets |
| 28 |
to change the others access to some executable, then anyone has the |
| 29 |
capability (if I understand correctly). |
| 30 |
|
| 31 |
> There are two reasons that granting the capability to the executable |
| 32 |
> isn't feasible: |
| 33 |
> |
| 34 |
> 1) Some of the programs are written in Python, and I don't want to |
| 35 |
> grant the capability to all Python programs by setting the |
| 36 |
> capability on /usr/bin/python. |
| 37 |
|
| 38 |
Again, create an executable with CAP_SETPCAP that executes the Python |
| 39 |
programs and sets the capabilities for the running program. |
| 40 |
|
| 41 |
> 2) Some of the programs are ELF executables (compiled C programs) |
| 42 |
> that are under developement and are being continuously re-built |
| 43 |
> and re-run. If I have to do a "sudo setcap" everytime I |
| 44 |
> compile/run a program, then I might as well just do "sudo |
| 45 |
> <program>" the way I do now. |
| 46 |
|
| 47 |
You can create (once) an executable with CAP_SETFCAP, which your build |
| 48 |
system calls automatically every time you recompile and that sets the |
| 49 |
CAP_NET_RAW capability for the resulting executable. Not very secure |
| 50 |
anyway, but I think it could work. |
| 51 |
|
| 52 |
>> A workaround for what you want is to write a little executable that |
| 53 |
>> only execvp's bash (or whatever shell you use), grant that executable |
| 54 |
>> CAP_NET_RAW, and then set it as default shell with usermod. |
| 55 |
> |
| 56 |
> I thought about that, but that seems fragile. |
| 57 |
|
| 58 |
> I supposed I could set the capability on /bin/bash with +p instead of |
| 59 |
> +ep, then it should only take effect for users who have the capability |
| 60 |
> enabled (though I haven't been able to get that to work yet). |
| 61 |
|
| 62 |
I think the problem is that you want to use capabilities in a way that |
| 63 |
they are not designed for: you don't set capabilities at development |
| 64 |
time, you do it at deployment time. I would develop in a container or |
| 65 |
a VM until the program is ready and then deploy it with capabilities |
| 66 |
enabled. |
| 67 |
|
| 68 |
Regards. |
| 69 |
-- |
| 70 |
Canek Peláez Valdés |
| 71 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 72 |
Universidad Nacional Autónoma de México |
Archives