Setting rtable 0 from >1 with ping et al

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Setting rtable 0 from >1 with ping et al

Joe Holden-2
Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting rtable 0 from >1 with ping et al

Joe Holden-2
On 09/03/2017 23:02, Joe Holden wrote:

> Hi,
>
> So - it seems that pledge will deny a change of rtable to 0 when using
> level SOL_SOCKET and the current rtable is >0, so eg if you're in table
> 1 and you do ping -V0 it will fail.
>
> Can anyone shed any light on why this is restricted?  Especially since
> the same can be achieved with route -T0 exec
>
> Thanks!
>
Actually, just realised why it doesn't work - it drops privs before
setting rtable, nevermind.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting rtable 0 from >1 with ping et al

Joe Holden-2
On 09/03/2017 23:35, Joe Holden wrote:

> On 09/03/2017 23:02, Joe Holden wrote:
>> Hi,
>>
>> So - it seems that pledge will deny a change of rtable to 0 when using
>> level SOL_SOCKET and the current rtable is >0, so eg if you're in table
>> 1 and you do ping -V0 it will fail.
>>
>> Can anyone shed any light on why this is restricted?  Especially since
>> the same can be achieved with route -T0 exec
>>
>> Thanks!
>>
> Actually, just realised why it doesn't work - it drops privs before
> setting rtable, nevermind.
>
Something like:

Index: sbin/ping/ping.c
===================================================================
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.218
diff -u -p -r1.218 ping.c
--- sbin/ping/ping.c 22 Feb 2017 13:43:35 -0000 1.218
+++ sbin/ping/ping.c 16 Mar 2017 19:58:28 -0000
@@ -283,10 +283,6 @@ main(int argc, char *argv[])
  uid = getuid();
  gid = getgid();
  }
- if (setgroups(1, &gid) ||
-    setresgid(gid, gid, gid) ||
-    setresuid(uid, uid, uid))
- err(1, "unable to revoke privs");

  preload = 0;
  datap = &outpack[ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
  usage();
  }
  }
+
+ if (setgroups(1, &gid) ||
+    setresgid(gid, gid, gid) ||
+    setresuid(uid, uid, uid))
+ err(1, "unable to revoke privs");

  argc -= optind;
  argv += optind;


perhaps, but haven't closely looked if there is any scope for escalation
or anything during option parsing

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting rtable 0 from >1 with ping et al

Florian Obser-2
On Thu, Mar 16, 2017 at 07:59:44PM +0000, Joe Holden wrote:

> On 09/03/2017 23:35, Joe Holden wrote:
> >On 09/03/2017 23:02, Joe Holden wrote:
> >>Hi,
> >>
> >>So - it seems that pledge will deny a change of rtable to 0 when using
> >>level SOL_SOCKET and the current rtable is >0, so eg if you're in table
> >>1 and you do ping -V0 it will fail.
> >>
> >>Can anyone shed any light on why this is restricted?  Especially since
> >>the same can be achieved with route -T0 exec
> >>
> >>Thanks!
> >>
> >Actually, just realised why it doesn't work - it drops privs before
> >setting rtable, nevermind.
> >
> Something like:
>
> Index: sbin/ping/ping.c
> ===================================================================
> RCS file: /cvs/src/sbin/ping/ping.c,v
> retrieving revision 1.218
> diff -u -p -r1.218 ping.c
> --- sbin/ping/ping.c 22 Feb 2017 13:43:35 -0000 1.218
> +++ sbin/ping/ping.c 16 Mar 2017 19:58:28 -0000
> @@ -283,10 +283,6 @@ main(int argc, char *argv[])
>   uid = getuid();
>   gid = getgid();
>   }
> - if (setgroups(1, &gid) ||
> -    setresgid(gid, gid, gid) ||
> -    setresuid(uid, uid, uid))
> - err(1, "unable to revoke privs");
>
>   preload = 0;
>   datap = &outpack[ECHOLEN + ECHOTMLEN];
> @@ -427,6 +423,11 @@ main(int argc, char *argv[])
>   usage();
>   }
>   }
> +
> + if (setgroups(1, &gid) ||
> +    setresgid(gid, gid, gid) ||
> +    setresuid(uid, uid, uid))
> + err(1, "unable to revoke privs");
>
>   argc -= optind;
>   argv += optind;
>
>
> perhaps, but haven't closely looked if there is any scope for
> escalation or anything during option parsing
>

This seems... unwise. ping(8) very carefuly tries to do as little as
possible while still having priviledges, i.e. only create raw sockets.

That being said, I don't understand the problem.

1) How do you end up in rtable 1 and need to do something in table 0?
2) you say route -T0 exec works, I don't think so:

$ route -T1 exec /bin/sh
$ route -T0 exec ping 8.8.8.8
route: setrtable: Operation not permitted

setrtable(2) has this:

ERRORS
     The call succeeds unless:
[...]
     [EPERM]            The user is not the superuser and the routing table of
                        the calling process is already set to a non-zero
                        value.

So this is intentional behaviour.

--
I'm not entirely sure you are real.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting rtable 0 from >1 with ping et al

Joe Holden-2
On 18/03/2017 08:21, Florian Obser wrote:

> On Thu, Mar 16, 2017 at 07:59:44PM +0000, Joe Holden wrote:
>> On 09/03/2017 23:35, Joe Holden wrote:
>>> On 09/03/2017 23:02, Joe Holden wrote:
>>>> Hi,
>>>>
>>>> So - it seems that pledge will deny a change of rtable to 0 when using
>>>> level SOL_SOCKET and the current rtable is >0, so eg if you're in table
>>>> 1 and you do ping -V0 it will fail.
>>>>
>>>> Can anyone shed any light on why this is restricted?  Especially since
>>>> the same can be achieved with route -T0 exec
>>>>
>>>> Thanks!
>>>>
>>> Actually, just realised why it doesn't work - it drops privs before
>>> setting rtable, nevermind.
>>>
>> Something like:
>>
>> Index: sbin/ping/ping.c
>> ===================================================================
>> RCS file: /cvs/src/sbin/ping/ping.c,v
>> retrieving revision 1.218
>> diff -u -p -r1.218 ping.c
>> --- sbin/ping/ping.c 22 Feb 2017 13:43:35 -0000 1.218
>> +++ sbin/ping/ping.c 16 Mar 2017 19:58:28 -0000
>> @@ -283,10 +283,6 @@ main(int argc, char *argv[])
>>   uid = getuid();
>>   gid = getgid();
>>   }
>> - if (setgroups(1, &gid) ||
>> -    setresgid(gid, gid, gid) ||
>> -    setresuid(uid, uid, uid))
>> - err(1, "unable to revoke privs");
>>
>>   preload = 0;
>>   datap = &outpack[ECHOLEN + ECHOTMLEN];
>> @@ -427,6 +423,11 @@ main(int argc, char *argv[])
>>   usage();
>>   }
>>   }
>> +
>> + if (setgroups(1, &gid) ||
>> +    setresgid(gid, gid, gid) ||
>> +    setresuid(uid, uid, uid))
>> + err(1, "unable to revoke privs");
>>
>>   argc -= optind;
>>   argv += optind;
>>
>>
>> perhaps, but haven't closely looked if there is any scope for
>> escalation or anything during option parsing
>>
>
> This seems... unwise. ping(8) very carefuly tries to do as little as
> possible while still having priviledges, i.e. only create raw sockets.
>
> That being said, I don't understand the problem.
>
> 1) How do you end up in rtable 1 and need to do something in table 0?
In this instance, the management (sshd, et al) rtable isn't 0 (for a few
reasons, mostly things that can't operate on an rtable other than 0)

> 2) you say route -T0 exec works, I don't think so:
>
> $ route -T1 exec /bin/sh
> $ route -T0 exec ping 8.8.8.8
> route: setrtable: Operation not permitted
>
> setrtable(2) has this:
>
> ERRORS
>      The call succeeds unless:
> [...]
>      [EPERM]            The user is not the superuser and the routing table of
>                         the calling process is already set to a non-zero
>                         value.
>
> So this is intentional behaviour.
>
Setting rtable implies being uid 0, so not really - but:

# ping -V0 127.0.0.1
ping: setsockopt SO_RTABLE: Operation not permitted
# route -T0 exec ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.948 ms

from an rtable other than 0, because the route doesn't use SO_RTABLE so
doesn't fail

Loading...