grsecurity and sshd, denied access to pid/mem entry
Posted: Thu Mar 13, 2003 7:49 amhello,
i'm using grsecurity-1.9.9c and vanilla-linux-2.4.20 on a redhat-8.0.
sshd is still bitching at me about pid/mem entries being denied access to,
like shown in the following log snippet:
Mar 13 12:45:28 scooter kernel: grsec: From 192.168.1.152: denied access to pid/mem entry of (sshd:8095) UID(0) EUID(0), parent (sshd:7987) UID(0) EUID(0) by (sshd:8095) UID(0) EUID(0), parent (sshd:7987) UID(0) EUID(0)
Mar 13 12:45:28 scooter sshd(pam_unix)[8095]: session opened for user ns by (uid=0)
Mar 13 12:45:28 scooter kernel: grsec: From 192.168.1.152: denied access to pid/mem entry of (sshd:20565) UID(0) EUID(0), parent (sshd:8095) UID(0) EUID(0) by (sshd:20565) UID(0) EUID(0), parent (sshd:8095) UID(0) EUID(0)
Mar 13 12:45:30 scooter sshd(pam_unix)[8095]: session closed for user ns
the learning mode does not accomplish this pid/mem entry thing, in such a way, that the acl is not being altered in learning mode. when replacing the acl with the newly learned one, the access to the pid/mem entry is still denied.
other parts of the acl do not suggest clues about this pid/mem to me.
i'm not really worried about this pid/mem denial, since the sshd seems to work fine nevertheless, but i'd like to know what it means and how to silence it, properly.
thanks, grsecurity is a great thing!
greetings nicolai/[0]
i'm using grsecurity-1.9.9c and vanilla-linux-2.4.20 on a redhat-8.0.
sshd is still bitching at me about pid/mem entries being denied access to,
like shown in the following log snippet:
Mar 13 12:45:28 scooter kernel: grsec: From 192.168.1.152: denied access to pid/mem entry of (sshd:8095) UID(0) EUID(0), parent (sshd:7987) UID(0) EUID(0) by (sshd:8095) UID(0) EUID(0), parent (sshd:7987) UID(0) EUID(0)
Mar 13 12:45:28 scooter sshd(pam_unix)[8095]: session opened for user ns by (uid=0)
Mar 13 12:45:28 scooter kernel: grsec: From 192.168.1.152: denied access to pid/mem entry of (sshd:20565) UID(0) EUID(0), parent (sshd:8095) UID(0) EUID(0) by (sshd:20565) UID(0) EUID(0), parent (sshd:8095) UID(0) EUID(0)
Mar 13 12:45:30 scooter sshd(pam_unix)[8095]: session closed for user ns
the learning mode does not accomplish this pid/mem entry thing, in such a way, that the acl is not being altered in learning mode. when replacing the acl with the newly learned one, the access to the pid/mem entry is still denied.
other parts of the acl do not suggest clues about this pid/mem to me.
i'm not really worried about this pid/mem denial, since the sshd seems to work fine nevertheless, but i'd like to know what it means and how to silence it, properly.
thanks, grsecurity is a great thing!
greetings nicolai/[0]