Fails to update IP address on hardened-gentoo: Feb 8 02:22:21 pluto [883845.727064] grsec: From 83.125.154.218: signal 11 sent to /sbin/ifconfig[ifconfig:25552] uid/euid:105/105 gid/egid:105/105, parent /bin/bash[sh:25551] uid/euid:105/105 gid/egid:105/105 Feb 8 02:22:21 pluto [883845.727110] grsec: From 83.125.154.218: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /sbin/ifconfig[ifconfig:25552] uid/euid:105/105 gid/egid:105/105, parent /bin/bash[sh:25551] uid/euid:105/105 gid/egid:105/105 ddclient should use iproute2 instead of ifconfig Reproducible: Always
Created attachment 181456 [details, diff] changed ebuild to use iproute2
Created attachment 181457 [details, diff] patch for ddclient to use iproute2
The patch was created for ddclient 3.7.1 but applies fine to ddclient 3.8.0, too.
Cilly, are you sure this is caused by the use of a hardened setup? The log excerpt conveys the real issue which is that ifconfig is segfaulting. However, no conclusion can be drawn as to why on the basis of that alone. Which parameters are passed to ifconfig at that point? You could turn on exec logging to find out.
> Cilly, are you sure this is caused by the use of a hardened setup? The log > excerpt conveys the real issue which is that ifconfig is segfaulting. Talked a while ago with solar and the reason is, that ifconfig does not give the IP-address if executed as unprivileged user. This is a side-effect of hardened. $ ifconfig Warning: cannot open /proc/net/dev (No such file or directory). Limited output. ddclient runs as user 'ddclient'.
Ah, yes - I remember now. Turning on /proc restrictions (CONFIG_GRKERNSEC_PROC) exposes (the very much related) bug 238363. The real problem here is ifconfig; it is in a thoroughly dilapidated state and I agree that making use of iproute2 is a sensible thing to do.
I have just bumped into this very bug. I've checked the current 3.7.3-r1 and 3.8.0 ebuilds and neither include this patch. Any progress into releasing this? I'll be switching to use=web as a workaround in the meantime.
As a workaround for now add CONFIG_GRKERNSEC_PROC_USERGROUP=y and CONFIG_GRKERNSEC_PROC_GID=<groupid> then add the ddclient user to the proc group to allow it to access /proc/net/dev. That's how I do it on my box currently.
It's been a while now. Does this issue still persist?
(In reply to comment #9) > It's been a while now. Does this issue still persist? Yes.
I'd suggest to add a hardened useflag to ddclient which inherits iproute2 and adds iproute patch. For non-hardened users, ifconfig will work as unprivileged user ddclient.
(In reply to comment #11) > I'd suggest to add a hardened useflag to ddclient which inherits iproute2 and > adds iproute patch. For non-hardened users, ifconfig will work as unprivileged > user ddclient. My thoughts exactly. Thanks for the quick response. Look for a fix tonight.
13 Aug 2011; Aaron W. Swenson <titanofold@gentoo.org> +files/iproute2.patch, +ddclient-3.8.1-r1.ebuild, metadata.xml: Fixes bug 258343
