Every sunday pppoe gets disabled

[Malkec]

Hi! I'm using grsec 2.6.19.2 and debian 4.0 testing. Every sunday I get disconnected from the internet because grsec won't allow pppoe to refresh. I'm not able to figure out why pppoe refreshes once a week anyway, I'd guess it has something to do with /usr/sbin/cron. Any ideas? P.S. I'm using gradm too.

Code: Select all

Jan 27 16:24:08 localhost kernel: grsec: (default:D:/) denied connect() to the unix domain socket /dev/log by /usr/sbin/pppd[pppd:2017] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 27 16:24:08 localhost last message repeated 3 times
Jan 27 16:24:08 localhost kernel: grsec: (default:D:/) use of CAP_NET_ADMIN denied for /usr/sbin/pppd[pppd:2017] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jan 27 16:24:08 localhost kernel: grsec: more alerts, logging disabled for 10 seconds
Jan 27 16:24:46 localhost kernel: grsec: (default:D:/) use of CAP_NET_RAW denied for /usr/sbin/pppd[pppd:2017] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

[Kp]

Based on the log messages you posted, you are not permitting pppd to access /dev/log, so you are losing any status messages it is trying to write to the system log. Additionally, you are denying it use of the CAP_NET_ADMIN and CAP_NET_RAW capabilities, which are probably necessary for its proper operation. Refer to a listing of system capabilities for more information about what these capabilities permit a process to do. You can find other listings by searching Google for the symbolic capability names.

Summary version: you need to change the RBAC rules for pppd so that it has the access necessary to do its job.

[Malkec]

Kp thanks for your reply!

But because there is such lack of information and examples on how to use RBAC(gradm) I can't figure out how to do it. I can only activate the system learning.

[ralphy]

Well, this is probably wrong but my guess is it would be in the vicinity of

Code: Select all

subject /usr/sbin/pppd
/dev/log rw
+CAP_NET_RAW
+CAP_NET_ADMIN


Perhaps Kp or Spender could advise if this is correct? Additionally, http://www.grsecurity.net/gracldoc.pdf is a good place to read up on grsec policies.

[PaX Team]

I can only activate the system learning.

if your run learning over a sunday, it should discover the extra privileges that pppd needs.

[Malkec]

Thanks for your help!

I've got two more problems.

1. I run boinc (distributed computing) and everytime I enable gradm it terminates the boinc (cannot use shared memory or smth like that). When I enable gradm I get this warning:

Code: Select all

Warning: write access is allowed to your subject for /home/malkec/BOINC/boinc in role malkec.  Please ensure that the subject is running with less privilege than the default subject.

2. While gradm is enabled, I can't do any commands like w, netstat, ps aux (root user) but I can do all these commands with uid=1001 user (special group user). What am I doing wrong?

I will leave the learning mode on for a week now to see what happens. Won't do anything on the server. Just hope gradm won't stop boinc, which it already did when I enabled the learning mode. I hope boinc will start to run in an hour

[ralphy]

2. While gradm is enabled, I can't do any commands like w, netstat, ps aux (root user) but I can do all these commands with uid=1001 user (special group user). What am I doing wrong?

My guess is in your kernel config you have

Code: Select all

CONFIG_GRKERNSEC_PROC_GID=1001


so the gid 1001 can read /proc entries while all other processes can't. I think its safe to say that uid 1001 has gid 1001 as well, yes? You could probably just write ACL subjects for each of those binaries so they would work as any user given that they have the proper read access to the necessary files in /proc or add yourself to the gid 1001 group. The latter (adding yourself to the special group) would probably be a better idea, in my opinion anyways. I'm sure others will differ