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
