weird error with sshd

[halotron]

I get a rather weird error when trying to ssh to the machine running grsecurity 2.0 (kernel 2.6.5).

Code: Select all

Jun 22 10:06:51 Amanita kernel: grsec: From 133.228.11.21: use of CAP_SETUID denied for /usr/sbin/sshd[sshd:18462] uid/euid:0/0 gid/egid:65534/65534, parent /usr/sbin/sshd[sshd:23093] uid/euid:0/0 gid/egid:0/0


The weird thing is that it has that privilege.
I even gave subject sshd these privileges on role root:

Code: Select all

subject /usr/sbin/sshd o {
/ rwxcdmi
+CAP_ALL
}


Still same error.

Also, i made rules for the group with gid 65534 and subject sshd so it had CAP_SETUID. No luck.
Then I tried making a nested subject, since sshd is runing sshd, but then it complained that it was a duplicate rule, but i figure that nesting is not the correct solution here anyway.

The original looked like this:

Code: Select all

subject /usr/sbin/sshd lo {
   /            h
   /bin            x
   /dev            h
   /dev/log         rw
   /dev/null         rw
   /dev/ptmx         rw
   /dev/pts         rw
   /dev/tty         rw
   /etc            rw
   /etc/grsec         h
   /etc/passwd         h
   /home            r
   /lib            rx
   /proc            r
   /proc/kcore         h
   /proc/sys         h
   /usr            h
   /usr/lib         rx
   /usr/sbin/sshd         x
   /usr/share/zoneinfo      r
   /var            
   /var/run         h
   /var/run/.nscd_socket      rw
   /var/run/sshd         
   /var/run/sshd.pid      wcd
   /var/run/utmp         rw
   /var/log         
   /var/log/lastlog      rw
   /var/log/wtmp         w
   /root            
   /root/.ssh         
   /root/.ssh/authorized_keys   r
   -CAP_ALL
   +CAP_CHOWN
   +CAP_DAC_OVERRIDE
   +CAP_SETGID
   +CAP_SETUID
   +CAP_SYS_CHROOT
   +CAP_SYS_RESOURCE
   +CAP_SYS_TTY_CONFIG
   +CAP_NET_BIND_SERVICE
   bind 0.0.0.0/32 dgram ip
   connect 133.228.11.0/24 stream dgram tcp udp
}


Any ideas?

[bmcmurphy]

Do you have a "role_allow_ip" statement for the root role that covers the IP address in question? Something like:

[code]role_allow_ip 133.228.11.21/32[/code]

[halotron]

Do you have a "role_allow_ip" statement for the root role that covers the IP address in question?

Yes, root has role_allow_ip 133.228.0.0/16

[bmcmurphy]

Sounds like another part of your policy is taking precedence. Care to post the rest of your acl file?

[halotron]

Sounds like another part of your policy is taking precedence. Care to post the rest of your acl file?

Apparently i got cracked, and that might explain the oddities. The interesting thing is that I probably had grsecurity in full learning mode when it was cracked. Anyone knows how to use the learning log in order to see what exactly happened during the crack?

[halotron]

Apparently i got cracked, and that might explain the oddities.

No it didnt, it was my friends who joked with me and got root :-P
Anyway, I'll just make a new full system learning and will post if I run into this again.