Grsec learner doesn't get socket permissions right
Posted: Thu Jan 15, 2015 6:34 pm
Hi,
I noticed a while ago that the learner seems to have problems with sockets. For instance, a while ago I set a machine into learning mode and logged in through ssh many times. However, once the policy was compiled an activated, the system refused to let me in straight away. The problem was that the learner decided to declare bind disabled for sshd when in fact bind 0.0.0.0/32:22 stream tcp was the right thing (or at least the problem disappeared), see my other post https://forums.grsecurity.net/viewtopic.php?f=5&t=3955#p13997
Now I am trying to figure out a policy for postfix which is composed of various services and daemons. I had the machine in learning mode for several weeks during which I received a lot of e-mail with bounces and everything, so pretty many execution paths were tried. Yet, after creating and activating a policy the system complained instantly with
The policy for smtpd is (mostly generated from the learning logs and slightly adjusted)
Interestingly, for user postfix the learner did the right thing (bind 0.0.0.0/32:25 stream dgram ip tcp). However, after adjusting the rule for root:U:/usr/libexec/postfix/smtpd I received the next complaint
and this time there was no "free ride" to solve the problem.
Is there any way to deal with this problem of socket permissions?
I noticed a while ago that the learner seems to have problems with sockets. For instance, a while ago I set a machine into learning mode and logged in through ssh many times. However, once the policy was compiled an activated, the system refused to let me in straight away. The problem was that the learner decided to declare bind disabled for sshd when in fact bind 0.0.0.0/32:22 stream tcp was the right thing (or at least the problem disappeared), see my other post https://forums.grsecurity.net/viewtopic.php?f=5&t=3955#p13997
Now I am trying to figure out a policy for postfix which is composed of various services and daemons. I had the machine in learning mode for several weeks during which I received a lot of e-mail with bounces and everything, so pretty many execution paths were tried. Yet, after creating and activating a policy the system complained instantly with
- Code: Select all
blah blah blah: grsec: (root:U:/usr/libexec/postfix/smtpd) denied socket(inet,stream,ip) by /usr/libexec/postfix/smtpd[smtpd:1198] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:1061] uid/euid:0/0 gid/egid:0/0
The policy for smtpd is (mostly generated from the learning logs and slightly adjusted)
- Code: Select all
subject /usr/libexec/postfix/smtpd do {
user_transition_allow postfix
group_transition_allow postfix
/ h
/dev h
/dev/log rw
/dev/urandom r
/etc r
/etc/grsec h
/etc/gshadow h
/etc/gshadow- h
/etc/shadow h
/etc/shadow- h
/etc/ssh h
/etc/stunnel h
/lib rx
/lib/modules h
/proc h
/proc/sys/kernel/ngroups_max r
/sys h
/sys/devices/system/cpu/online r
/usr h
/usr/lib rx
/usr/libexec h
/usr/libexec/postfix/smtpd x
/var h
/var/spool/postfix rw
/var/tmp
-CAP_ALL
+CAP_DAC_READ_SEARCH
+CAP_SETGID
+CAP_SETUID
bind disabled
connect disabled
sock_allow_family unix inet ipv6 netlink
}
Interestingly, for user postfix the learner did the right thing (bind 0.0.0.0/32:25 stream dgram ip tcp). However, after adjusting the rule for root:U:/usr/libexec/postfix/smtpd I received the next complaint
- Code: Select all
blah blah blah: grsec: (root:U:/usr/libexec/postfix/anvil) denied socket(inet,stream,ip) by /usr/libexec/postfix/anvil[anvil:1389] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:1061] uid/euid:0/0 gid/egid:0/0
and this time there was no "free ride" to solve the problem.
Is there any way to deal with this problem of socket permissions?