grsecurity forums

HI

when the GRsecurity kernel is patched all the remote console wil fail
for example when I want to login the password appears rather than being hidden in the login

when trying to edit something using text editor it will end up displaying [/A or something like this
I noticed there is an old topic abot this issue here
viewtopic.php?f=3&t=2022
but were not an absolute fix
is there any body there have this fixed?

Thanks

just like last time it came up, can you first verify that a vanilla kernel of the same version works fine? then it may help if you posted your grsec kernel config, rbac rules, possibly related systems logs (if any), etc. also if vanilla works, you could strace a misbehaving app (like login or the editor) on both kernels then we can compare them and perhaps spot the difference.

Hi,

The kernel has been installed with the ASL Atomicorp which is customized grsecurity kernel by them and all the configuration is what they have provided by default
Do you still need me to provide the configuration or not since it is default ASL configuration?

Thanks

Hi woshka,

You will have to make sure the grsecurity "chroot_caps" sysctl entry is disabled at early boot time, then enable it at a later time. A background script launched from rc.local that enables after a sleep of 10 seconds or so should do the trick, as getty is launched after the init scripts complete. Alternatively (at a reduced security level) you can disable CONFIG_GRKERNSEC_CHROOT_CAPS entirely. The problem is that plymouthd is doing a chroot(.) and then trying to use various capabilities that in general would allow a vulnerability in the process to break out of the chroot. Grsecurity's feature denies use of those capabilities, and if you were to check your kernel logs, you'd see something like the following:

grsec: use of CAP_SYS_TTY_CONFIG in chroot denied for/bin/plymouthd[plymouthd:135] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: use of CAP_SYS_ADMIN in chroot denied for /bin/plymouthd[plymouthd:135] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

This will only happen with plymouthd, so anything running Fedora 15+ or RHEL6, and only appears to matter for tty1.

I've discussed some potential solutions with Atomicorp, so they should have a fix for this issue in the future.

-Brad

Hi,

I know this is an old thread, but I'll post here for folks who run into this problem and need a solution other than enabling grsec sysctl.

The problem is that plymouth locks the termios, and then it does chroot before it unlocks the termios. So, the termios get stuck in unbuffered mode. The getty handles that OK, but login does not, which causes the password entry failure.

One solution is to run a small program (from rc.local) to unlock the termios. I don't believe stty has this capability, but you can compile the following small C program to do it. Run this by redirecting stdin from the serial port in question (like how stty works):

Code: Select all

#include <termios.h>
#include <sys/ioctl.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>

int
main(int argc, char* argv[])
    {
    struct termios trm;

        memset(&trm, 0, sizeof(struct termios));
        ioctl(0, TIOCSLCKTRMIOS, &trm);

    return 0;
    }

This should have been resolved with the introduction of the GRKERNSEC_CHROOT_INITRD feature. Have you given that a try?

-Brad