FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 07-26-2011, 12:59 PM
Tom Horsley
 
Default binding socket fails when run under ptrace?

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 01:05 PM
"Bryn M. Reeves"
 
Default binding socket fails when run under ptrace?

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 01:29 PM
Tom Horsley
 
Default binding socket fails when run under ptrace?

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?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 01:37 PM
Chris Adams
 
Default binding socket fails when run under ptrace?

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".
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 01:37 PM
Sam Varshavchik
 
Default binding socket fails when run under ptrace?

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.


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 01:54 PM
"Bryn M. Reeves"
 
Default binding socket fails when run under ptrace?

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 02:05 PM
Tom Horsley
 
Default binding socket fails when run under ptrace?

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 04:00 PM
"Bryn M. Reeves"
 
Default binding socket fails when run under ptrace?

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 07-26-2011, 04:01 PM
"Bryn M. Reeves"
 
Default binding socket fails when run under ptrace?

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@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 07:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org