binding socket fails when run under ptrace?

Bryn M. Reeves bmr at redhat.com
Tue Jul 26 16:00:04 UTC 2011


On 07/26/2011 03:05 PM, Tom Horsley wrote:
> On Tue, 26 Jul 2011 14:54:18 +0100
> Bryn M. Reeves wrote:
> 
>> As others have said, that's how rsh "security" "works" - if you need to strace
>> the command as a non-root user you might be able to come up with something
>> involving dropping the file capability and granting cap_net_bind_service to the
>> user you need to strace as (obviously this grants that user the ability to bind
>> any port they like but for debugging you might chose to allow that).
> 
> I was looking for that, but can't find the slightest shred of evidence
> that a user can be granted a capability in any of the googling I have
> done. All I can find is setcap for granting a file capability.

There's a capsh command in the libcap package that lets you run a shell with a
modified set of capabilities but I'm not sure if it will help here - it's mostly
used for dropping caps for testing - I don't seem to be able to raise the
effective capabilities for a non-root uid:

[root at bmr ~]# capsh --keep=1 --uid=4444 --caps='
cap_net_raw,cap_net_bind_service+pei' --
[bmr at bmr ~]$ grep Cap /proc/self/status
CapInh:	0000000000002400
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	ffffffffffffffff

So the bits I asked for made it into the inherited capabilities mask but not the
permitted or effective (the +pi).. Not sure why this is - capabilities can be
configured so that once dropped they can never be regained via the bounding set
and prctl/PR_SET_SECUREBITS but I didn't think this was being done on Fedora yet?

Regards,
Bryn.


More information about the users mailing list