/dev/grsec in a chroot

[hmhansolo]

Hello all,
Quick question. I need to access /dev/grsec in a chroot. I have setup the device in the proper way. The acls are set correctly (there are no grsec access denied in `dmesg`). But, when I run any gradm command (status, auth, etc), i get the following message:


localhost logs # gradm -n admin
Could not open /dev/grsec.
open: Permission denied

I also cannot do a `cat /dev/grsec`... is there a limit to how many grsec devices there can be?


This is with the Openvz && Grsec work that I am doing.

--thanks

[spender]

You can't use /dev/grsec in a chroot. There can only be one /dev/grsec, and it may only exist on the real filesystem.

-Brad

[hmhansolo]

Is this due to a specific design decision/issue.. like in grsec or in the kernel.. or is there a specific check that grsec does to see if the /dev/grsec is being access from within a chroot.. and if so, where in the code is it?

I was going through the sys_write function, trying to find where the permission was denied.. Didn't know if it was the system, fs acls, grsec acls, openvz, etc... I think I was thrown off by the stupid LSM hooks and ended up looking in the wrong area. Kinda cool mukin around in the kernel. Gonna put some printk's and then boot the kernel in a VM and see what happens. next. =)

But, if you can direct me to where to go, that would be quicker.

I can understand that accessing /dev/grsec in a chroot is not smart or good at all.., and is in fact really bad security wise... however, in my current setup with grsec and openvz, the chroot's are more like virtual environments with their own identity. They have their own network environment/stack (openvz has a separate network driver for VE's) and everything. So, if I have a virtual environment (VE) for my mysql server, I want to be able to let the mysql admin authenticate to grsec as the admin_mysql user to run mysql admining commands, without having to login to the actual host machine. Unlike chroot's, VE's are actually built to practically be their own separate machine. That's why in the VE's being able to authenticate as special roles would be important.

Perhaps there is some other way to authenticate to grsec? A way where you can enter an authenticated role... but you cant run `gradm -D` or `gradm -R`, etc...

Thanks
--hmhansolo

[hmhansolo]

Well, over the last few weeks I have been having some serious fun.. using virtual machines and what not, i have been doing some serious kernel debugging/hacking..

my tools:
-printk Yay!
-systemtap (coolest thing over.. on demand, dymanic printk's)..
looked into kdb or kgdb, but never actually got to it.. systemtap and manual code printk's when systemtap failed, worked more or less well enuff for me..

Basically, I figured out 2 things... one openvz needs to be configured to allow the use of devices that aren't in the default set.. apparently this info was in the 112 page documentation, but no where easily accessible in the faq or wiki.. so i didn't know about it...

After overcomming openvz blocking my access, I got around to figuring out why grsec was blocking access... openvz was blocking access on the open call.. grsec was blocking access on the write system call...

basically, i drilled down to the following code in write_grsec_handler@grsecurity/gracl.c

Code: Select all

if ((gr_status & GR_READY) && !(current->acl->mode & GR_KERNELAUTH))

Basically, for anything in the chroot, GR_KERNELAUTH wasn't set in the mode.. after digging further into the grsecurity code in the kernel and gradm, I figured out how to get that mode set..

so, there is a subject mode option called 'a'... when a subject is given mode 'a' in the policy, then it can have access to /dev/grsec... i never knew of this, because I am assuming that the / subject is automatically by default given the 'a' mode, so I have never had to specify it..

anyways, after giving the gradm in the chroot the 'a' subject mode, it could now authenticate to the kernel.. yay!!

so, now that I got that figured out, I am going to get back to working on the openvz/grsec patchset.. run some openvz environments for a couple weeks, try some well know servers like apache, and ftp server.. stress the server in their openvz environments under grsec policy protections.. and if all goes well, I will make another post regarding where you can get the patchset..

mind u.. this is a couple of weeks worth of time that I will spend... but i'll prolly spread this couple of weeks worth of time over a month or two.. =)..

maybe within a month i'll post an update or so..


--hmhansolo