grsecurity forums

When i want to set password for special role, gradm asks for password twice, then writes 'Password written to /etc/grsec/pw.' and freezes.

I`m using gentoo and sys-apps/gradm-2.1.6.200506131347.

kernel is 2.4.31-hardened.

something strange with my system: it seems like grsecurity has locked itself.
I actively write policies, start and stop grsecurity ACL system, and in some moment i have this:

i am root, under 'admin' special role, which is allowed to do all. i`ve changed some ACLs and want to restart grsec with new ACLs.

Now i run 'gradm -D' and enter password. It complains about 'invalid password' and nothing happens.

When i run gradm -S it shows nothing.

I ran strace gradm -S and here is result:

Code: Select all

..........
brk(0x8421000)                          = 0x8421000
getcwd("/etc/grsec/roles/root", 4095)   = 22
mlock(0x5a1b20f0, 256)                  = 0
ioctl(0, TIOCEXCL, 0)                   = 0
open("/dev/grsec", O_WRONLY)            = 3
write(3, "0\376\32Z\26\2\0\0\34\1\0\0", 12) = -1 EPERM (Operation not permitted)
close(3)                                = 0
ioctl(0, TIOCNXCL, 0xc)                 = 0
exit_group(0)                           = ?


gradm is unable to open /dev/grsec ?

I ran then strace gradm -D: (pass is set to 'secret')

Code: Select all

....
getcwd("/etc/grsec/roles/root", 4095)   = 22
mlock(0x5f3ad530, 256)                  = 0
ioctl(0, TIOCEXCL, 0)                   = 0
open("/dev/grsec", O_WRONLY)            = 3
write(3, "p\262:_\26\2\0\0\34\1\0\0", 12) = -1 EPERM (Operation not permitted)
close(3)                                = 0
mlock(0x5f3ab250, 256)                  = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2db84000
write(1, "Password: ", 10Password: )              = 10
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon -echo ...}) = 0
read(0, "secret\n", 128)                = 7
write(1, "\n", 1
)                       = 1
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
mlock(0x85f8718, 284)                   = 0
open("/dev/grsec", O_WRONLY)            = 3
write(3, "\30\207_\10\26\2\0\0\34\1\0\0", 12) = -1 EPERM (Operation not permitted)
write(2, "Invalid password.\n", 18Invalid password.
)     = 18
close(3)                                = 0
ioctl(0, TIOCNXCL, 0x12)                = 0
munmap(0x2db84000, 4096)                = 0
exit_group(1)                           = ?


What`s going on?

Currently , i have such situation: 2 consoles with root logged in.
On one console i was root and enabled ACL system by gradm -E
On the other, i was root and auth`ed to special role

On the 1st , i disabled & enabled it again.

So:
1st console: gradm -S: The RBAC system is currently enabled.
2nd console: nothnig

1st console: -bash: /usr/local/bin/vim: Permission denied
2nd console: vim - running vim ok

1st console: gradm -u:You are not in a special role.
2nd console: gradm -u:You are not in a special role

But on 2nd console i`m able to run everything! (as i`m in special role), but gradm -S has problems, i`v noticed in my previous post.

i`ve made some more test and it seems that:

somehow grsecuirty is blocking itself in open console.

How do i work: i ssh to server in 3 terminals and login as root: one terminal to view messages in logs, one to enter root commands and 1 for logging as user.

After some time and some times doing 'gradm -D/E' root consoles becomes blocked: i`m unable to run grad -D, -S, although policies seem to work: if i`m in specail role, i can run everything, if not - only allowed apps.

But i`m able to login thorough ssh and run 'gradm -D'. After this action, 'blocked' terminals start working again.

gradm -P will "freeze" or "hang" if there is not enough randomness to generate the password crypts, but it says that it has been "written to /etc/grsec/pw" before it's fully completed. On gentoo, a good way of getting some quick randomness is running an emerge --sync, but on other systems anything with network or disk activity like a find, or updatedb, compress a large directory, etc, should help. If it is freezing like something is wrong, try running some randomness-generating process in the background and you should see that process complete successfully.

The gradm -P hanging problem has been fixed in current CVS. It was unnecessary to try to use /dev/random, since randomness was only needed for the (large) salt, which is essentially secret, along with the rest of the hash, unlike an /etc/shadow file on a normal system, so /dev/urandom is sufficient.

-Brad

thanks!

thanks twice =)