| 1 |
On 2013-12-10, Canek Pel??ez Vald??s <caneko@×××××.com> wrote: |
| 2 |
|
| 3 |
>> But the example provided only shows how to grant capabilities to a |
| 4 |
>> user that can then be inherited by files which must also have that |
| 5 |
>> same capability enabled. That's not quite what I want to do (and it |
| 6 |
>> doesn't seem to work). |
| 7 |
> |
| 8 |
> The restriction to files already having the capability is for security |
| 9 |
> reasons, obviously: if a user has certain capability, and she forgets |
| 10 |
> to change the others access to some executable, then anyone has the |
| 11 |
> capability (if I understand correctly). |
| 12 |
|
| 13 |
No, that's not how it works. You can use pam_cap to grant an |
| 14 |
inheritable capability to a user, but it can only be used by files |
| 15 |
that also have the capability to inherit that capability. |
| 16 |
|
| 17 |
There are basically two ways you can set a capability on a file: the |
| 18 |
file can have the capability regardless of the user, or the file can |
| 19 |
have the capability only if it can be inherited from the user. |
| 20 |
|
| 21 |
If you grant a capability to a file using "setcap cap_whatever+ei |
| 22 |
myprog" then it's only effective for users that also have cap_whatever |
| 23 |
enabled in /etc/security/capability.conf |
| 24 |
|
| 25 |
If you grant a capability to a file using "setcap cap_whatever+ep", |
| 26 |
then it's available to all users. |
| 27 |
|
| 28 |
> Again, create an executable with CAP_SETPCAP that executes the Python |
| 29 |
> programs and sets the capabilities for the running program. |
| 30 |
|
| 31 |
[...] |
| 32 |
|
| 33 |
> You can create (once) an executable with CAP_SETFCAP, which your |
| 34 |
> build system calls automatically every time you recompile and that |
| 35 |
> sets the CAP_NET_RAW capability for the resulting executable. Not |
| 36 |
> very secure anyway, but I think it could work. |
| 37 |
|
| 38 |
It's a lot simpler to just continue using sudo to run the programs. |
| 39 |
|
| 40 |
>>> A workaround for what you want is to write a little executable that |
| 41 |
>>> only execvp's bash (or whatever shell you use), grant that executable |
| 42 |
>>> CAP_NET_RAW, and then set it as default shell with usermod. |
| 43 |
>> |
| 44 |
>> I thought about that, but that seems fragile. |
| 45 |
|
| 46 |
That wouldn't help. I've figured out how to give bash CAP_NET_RAW |
| 47 |
capabilities for a specified user, but it still requires that |
| 48 |
executables have the same capability set. |
| 49 |
|
| 50 |
>> I supposed I could set the capability on /bin/bash with +p instead of |
| 51 |
>> +ep, then it should only take effect for users who have the capability |
| 52 |
>> enabled (though I haven't been able to get that to work yet). |
| 53 |
|
| 54 |
That doesn't work either. Bash gets the privledges in question but |
| 55 |
they aren't inherited by programs invoked by bash unless they have |
| 56 |
already had those capabilities set. |
| 57 |
|
| 58 |
> I think the problem is that you want to use capabilities in a way that |
| 59 |
> they are not designed for: |
| 60 |
|
| 61 |
Apparently so. |
| 62 |
|
| 63 |
> you don't set capabilities at development time, you do it at |
| 64 |
> deployment time. I would develop in a container or a VM until the |
| 65 |
> program is ready and then deploy it with capabilities enabled. |
| 66 |
|
| 67 |
No, that's not the problem. The problem is that the whole system is |
| 68 |
designed to assign capabilities to _files_, and I want to assign a |
| 69 |
capablity to a user. |
| 70 |
|
| 71 |
-- |
| 72 |
Grant Edwards grant.b.edwards Yow! BELA LUGOSI is my |
| 73 |
at co-pilot ... |
| 74 |
gmail.com |
Archives