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.
