on ensim chrooting broken on ensim

[kamihacker]

Jan 5 22:57:51 hostname last message repeated 2 times
Jan 5 22:57:51 hostname kernel: grsec: more alerts, logging disabled for 10 seconds
Jan 5 22:57:51 hostname sendmail[18932]: sendto failed 1 : Operation not permitted
Jan 5 22:59:23 hostname kernel: grsec: From 200.44.33.13: denied connect to abstract AF_UNIX socket outside of chroot by (sendmail:3036) UID(0) EUID(0), parent (sendmail:1999) UID(0) EUID(0)
Jan 5 22:59:23 hostname sendmail: connect 1 : Operation not permitted
Jan 5 22:59:23 hostname kernel: grsec: From 200.44.33.13: denied connect to abstract AF_UNIX socket outside of chroot by (sendmail:14192) UID(0) EUID(0), parent (sendmail:3036) UID(0) EUID(0)
Jan 5 22:59:23 hostname sendmail[14192]: sendto failed 1 : Operation not permitted
Jan 5 22:59:23 hostname kernel: grsec: From 200.44.33.13: denied connect to abstract AF_UNIX socket outside of chroot by (sendmail:14192) UID(0) EUID(0), parent (sendmail:3036) UID(0) EUID(0)
Jan 5 22:59:23 hostname last message repeated 2 times
Jan 5 22:59:23 hostname kernel: grsec: more alerts, logging disabled for 10 seconds


any clue on which chrooting feature should be disabled?

could it be nested chrroting?

[Sleight of Mind]

CONFIG_GRKERNSEC_CHROOT_UNIX

or in the menu:

"Deny access to abstract AF_UNIX sockets out of chroot"

[kamihacker]

disable the next features and you'll have ensim up and runnning very swift (aside from not being able to let virtual users have a shell account because of some problem with the tty asigning, I haven't found out what's causing it)

disable this on your kernel configuration:

on Address Space Protection
Restrict mprotect()

on Filesystem Protections
Deny mounts
Deny double-chroots
Deny (f)chmod +s
Deny fchdir out of chroot
Deny access to abstract AF_UNIX sockets out of chroot
Capability restrictions within chroot

if any of you find out how to solve the notty problem on virtual users (must be related to chrooting in my opinion) plz reply

[DavidG]

Can these options be modified without recompiling kernel?

Regards,

David

[spender]

If you have the sysctl feature of grsecurity enabled, they can be enabled/disabled without rebooting, though if you disable the "deny sysctl writes in chroot" feature for example, and don't set the grsec_lock for the sysctl entries, you're negating a lot of the security provided by grsecurity.

-Brad