grsecurity forums

hello,

I was hoping if someone could give me some insight into narrowing this issue I am currently experiencing with my VNSTATD service. The VNSTATD service is started under 'systemd'. The log suggests that vnstatd setuid itself and I would assume that setuid system call inherits GID group?

Code: Select all

Jan 20 05:46:35 nemesis vnstatd[26585]: vnStat daemon 1.10 started.
Jan 20 05:46:35 nemesis vnstatd[26578]: Starting vnstatd ..done
Jan 20 05:46:35 nemesis vnstatd[26585]: Switching user to vnstat (105).
Jan 20 05:46:35 nemesis vnstatd[26585]: Monitoring: eth0
Jan 20 05:46:35 nemesis vnstatd[26585]: Error: Unable to get interface "eth0" statistics.
Jan 20 05:46:35 nemesis vnstatd[26585]: Interface "eth0" not available, disabling.


Code: Select all

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
vnstat   24473 24472  0 21735  2568   1 03:40 pts/2    00:00:00 -sh
vnstat   26585     1  0  4918   832   1 05:46 ?        00:00:00 /usr/sbin/vnstatd -d -p /var/run/vnstatd.pid -u vnstat


Code: Select all

CONFIG_GRKERNSEC_PROC_GID=1001

Code: Select all

uid=105(vnstat) gid=1001(staff) groups=1001(staff)

The odd behavior is if I 'su - vnstat' and run the command manually, the 'eth0' interface is detected, and it runs properly. I don't quite understand why when I execute it 'systemd start vnstatd.service' it fails to detect the 'eth0' interface. Furthermore, I am not quite sure if Grsecurity is playing a role in preventing 'VNSTATD' service under systemd is preventing the necessary access? Any assistance on this matter would be greatly helpful.

Hi markings,

You can verify what groups the process is running with by doing a cat /proc/pid/status and inspecting the "Groups:" line. I imagine this service is not calling setgroups() to add the proper supplementary groups. You'd have to file a bug with the developer.

-Brad