I just tried to run an "rsh" command under strace, and it always gets permission denied when it tries to bind the socket (fedora 15 64 bit). Is this some new helpful security feature I've never heard of?
tomh> strace -o working.trace rsh tomh date rcmd: socket: Permission denied
From the working.trace file:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(1023), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied)
not under strace:
tomh> rsh tomh date Tue Jul 26 08:56:29 EDT 2011
Here's the kernel:
tomh> uname -a Linux tomh 2.6.38.8-35.fc15.x86_64 #1 SMP Wed Jul 6 13:58:54 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Selinux is turned off, so that can't be it.
On 07/26/2011 01:59 PM, Tom Horsley wrote:
tomh> strace -o working.trace rsh tomh date rcmd: socket: Permission denied
It's presumably being having its capabilities dropped because you are ptracing an executable with the cap_net_bind_service capability as an unprivileged user (if it wasn't it would be a security hole as a regular user could use a debugger to bind arbitrary privileged ports).
Older releases had the same behaviour when ptracing SUID binaries - this is the same reason you cannot strace the ping command (requires a raw socket so is either SUID or cap_net_raw).
Regards, Bryn.
On Tue, 26 Jul 2011 14:05:59 +0100 Bryn M. Reeves wrote:
It's presumably being having its capabilities dropped because you are ptracing an executable with the cap_net_bind_service capability as an unprivileged user (if it wasn't it would be a security hole as a regular user could use a debugger to bind arbitrary privileged ports).
It is the rsh client program, why on earth would the rsh client need to bind a privileged port?
Once upon a time, Tom Horsley horsley1953@gmail.com said:
It is the rsh client program, why on earth would the rsh client need to bind a privileged port?
Because that's how rsh works for .rhosts and /etc/hosts.equiv processing. Connections from a privileged port are considered "trusted".
Tom Horsley writes:
On Tue, 26 Jul 2011 14:05:59 +0100 Bryn M. Reeves wrote:
It's presumably being having its capabilities dropped because you are
ptracing
an executable with the cap_net_bind_service capability as an unprivileged
user
(if it wasn't it would be a security hole as a regular user could use a
debugger
to bind arbitrary privileged ports).
It is the rsh client program, why on earth would the rsh client need to bind a privileged port?
So that it can prove to the rsh server that it's a connection from a privileged process; so if it says that this is user X connecting, it must really be user X.
On 07/26/2011 02:29 PM, Tom Horsley wrote:
On Tue, 26 Jul 2011 14:05:59 +0100 Bryn M. Reeves wrote:
It's presumably being having its capabilities dropped because you are ptracing an executable with the cap_net_bind_service capability as an unprivileged user (if it wasn't it would be a security hole as a regular user could use a debugger to bind arbitrary privileged ports).
It is the rsh client program, why on earth would the rsh client need to bind a privileged port?
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).
Regards, Bryn.
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.
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 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.
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.
-
Bryn M. Reeves -
Chris Adams -
Sam Varshavchik -
Tom Horsley