On 07/26/2011 05:00 PM, Bryn M. Reeves wrote:
> 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@bmr ~]# capsh --keep=1 --uid=4444 --caps='
> cap_net_raw,cap_net_bind_service+pei' --
> [bmr@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
^^ +pe ;)
> 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.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
