[gentoo-user] How to grant a CAP_NET_RAW capability to user?

[gentoo-user] How to grant a CAP_NET_RAW capability to user?

[Grant Edwards]

How do you grant a capability (e.g. CAP_NET_RAW) to a user?

I've been googling and have found countless articles and blog posts
explaining what each capability is and how to grant capabilities to an
executable file.  While granting the capability to an executable does
work, that's not what I need to do for a couple different reasons.

I need to grant the capability to a user, not to the executable.

There were a couple vague references implying that you can configure
"login to grant the desired capabilities" when a user logs in, but
I've not found any documentation on how to do that.

I've tried editing /etc/security/capability.conf and adding the line

  cap_net_raw   <username>

But, that doesn't seem to have any effect (yes, I logged out and back
in again).

-- 
Grant Edwards               grant.b.edwards        Yow! Mary Tyler Moore's
                                  at               SEVENTH HUSBAND is wearing
                              gmail.com            my DACRON TANK TOP in a
                                                   cheap hotel in HONOLULU!

Re: [gentoo-user] How to grant a CAP_NET_RAW capability to user?

[Canek Peláez Valdés]

From man:capabilities(7): "Capabilities are a per-thread attribute."

I don't think you can grant any capability to a user. 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.

Regards.

On Tue, Dec 10, 2013 at 12:16 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
> How do you grant a capability (e.g. CAP_NET_RAW) to a user?
>
> I've been googling and have found countless articles and blog posts
> explaining what each capability is and how to grant capabilities to an
> executable file.  While granting the capability to an executable does
> work, that's not what I need to do for a couple different reasons.
>
> I need to grant the capability to a user, not to the executable.
>
> There were a couple vague references implying that you can configure
> "login to grant the desired capabilities" when a user logs in, but
> I've not found any documentation on how to do that.
>
> I've tried editing /etc/security/capability.conf and adding the line
>
>   cap_net_raw   <username>
>
> But, that doesn't seem to have any effect (yes, I logged out and back
> in again).
>
> --
> Grant Edwards               grant.b.edwards        Yow! Mary Tyler Moore's
>                                   at               SEVENTH HUSBAND is wearing
>                               gmail.com            my DACRON TANK TOP in a
>                                                    cheap hotel in HONOLULU!
>
>



-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: How to grant a CAP_NET_RAW capability to user?

[Grant Edwards]

On 2013-12-10, Canek Pel??ez Vald??s <caneko@gmail.com> 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).

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).

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.

  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
     <program>" the way I do now.

> 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).

-- 
Grant Edwards               grant.b.edwards        Yow! My vaseline is
                                  at               RUNNING...
                              gmail.com            

Re: [gentoo-user] Re: How to grant a CAP_NET_RAW capability to user?

[Canek Peláez Valdés]

On Tue, Dec 10, 2013 at 12:56 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
> On 2013-12-10, Canek Pel??ez Vald??s <caneko@gmail.com> 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
>      <program>" 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.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: How to grant a CAP_NET_RAW capability to user?

[Grant Edwards]

On 2013-12-10, Canek Pel??ez Vald??s <caneko@gmail.com> 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            

[gentoo-user] Re: How to grant a CAP_NET_RAW capability to user?

[Grant Edwards]

On 2013-12-10, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> How do you grant a capability (e.g. CAP_NET_RAW) to a user?

After more googling, I found this page which describes exactly what
I'm trying to do:

https://github.com/constanze/GSoC2010_Gentoo_Capabilities/wiki/pam_cap-on-gentoo

Except it doesn't work: after modifying /etc/pam.d/system-auth and
/etc/security/capability.conf as indicated and logging out/in, pscap
shows no cap_net_raw for the user in question, and trying to run
programs that use RAW sockets fail:

 socket: Operation not permitted
 Error opening socket: Operation not permitted
 
I'm apparently missing something...

-- 
Grant Edwards               grant.b.edwards        Yow! Sign my PETITION.
                                  at               
                              gmail.com