grsecurity forums

Problem:
gradm -a admin says "Invalid password."

The same thing happens in KDE, using sudo -i, su -, bash, etc., but only if I enabled RBAC learning mode in /etc/init.d/boot.local instead of another way (note the strange /etc/init.d in the grep output). (and learning mode doesn't work at all in before.local). I got the idea to put it in that file from this page which puts it in rc.local which doesn't exist here.

peter@peter:~> sudo -i
peter's password:

peter:~ # gradm -a admin
Password:
Invalid password.

peter:~ # grep RBAC /proc/$$/status
RBAC: default:D:/etc/init.d


This works in any text tty, or ssh localhost.

peter@peter:~> ssh localhost
Enter passphrase for key '/home/peter/.ssh/id_rsa':
Last login: Tue Oct 7 15:51:48 2014 from console
Have a lot of fun...

peter@peter:~> sudo -i
peter's password:

peter:~ # gradm -a admin
Password:

peter:~ # grep RBAC /proc/$$/status
RBAC: admin:S:/


So what can I do to allow admin logins from KDE?
Is there a better place to activate learning mode while it is booting?

Thanks

By the way... Versions:

gradm-3.0-201408301734.tar.gz
grsecurity-3.0-3.16.3-201409282025.patch (the test version, not stable)
systemd-208-23.3

$ uname -a
Linux peter 3.16.3-grsec-peter-grsec+ #1 SMP PREEMPT Fri Oct 3 12:03:24 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux

My kernel is the linux-stable git repo v3.16.3 plus the grsec patch plus this vgaarb patch

To use the admin role, a given role needs a "role_transitions admin" line. It will report incorrect password even if the password is correct if that line isn't present. You shouldn't be authenticating to the admin role except by root though, and preferably through direct root logins.

-Brad

I understand what you're saying... it makes sense except I don't understand why it should have any effect since I wasn't enforcing RBAC, and it fails the same thing whether my /etc/grsec/policy file was the default policy which has such a role_transitions or the generated one (which didn't have one for the default role, but did for root). And also it does not fail if I put it in a regular init script, even if I use the same generated policy as before.

So I still think the most significant hint is the "/etc/init.d/" in this output

Code: Select all

    peter:~ # grep RBAC /proc/$$/status
    RBAC: default:D:/etc/init.d

Which only appears if I started learning mode in /etc/boot.local, and not if I start it myself (gradm -F -L ... or gradm -E) in a shell from within the desktop environment, or in a regular init script.

And also I think it affects the policy that is generated by full learning mode. I have subjects like this which I didn't have before putting the gradm learning command in boot.local:

Code: Select all

    # Role: root
    subject /etc/init.d o {
    ...
    }

    # Role: peter
    subject /etc/init.d o {
    user_transition_allow peter nobody root
    group_transition_allow nogroup users root
    ...
    }

The string "init.d" is not even found in the policy at all (so far) if I generate it using a regular init.d script instead of boot.local, whereas before, it was the largest subject, much like the current generated "subject /" one now (which also is missing the o).

Code: Select all

    role peter u
    role_allow_ip   0.0.0.0/32
    # Role: peter
    subject /  {
    ...

So I guess this is probably related to systemd making those files act different than the regular rc.local in traditional systems, and still unsolved at the root of the problem, but I'll just work around it by putting the learning/enforce commands in a regular init script, making the RBAC system take effect later and provide less protection (missing most of the init process).

Hi,

The inherit-learn entries for /etc/init.d should be removed from learn_config if you're making the (highly non-recommended) choice of starting learning prior to service startup. The next version of gradm will include a comment in the learn_config file for guidance on this. Since most processes would be created as descendants of the init scripts, nearly all of the accesses would be grouped into those single subjects it created in each role (as is expected from inherit-learn rules).

-Brad

The inherit-learn entries for /etc/init.d should be removed from learn_config if you're making the (highly non-recommended) choice of starting learning prior to service startup.

What's wrong with that?

countermode wrote:

The inherit-learn entries for /etc/init.d should be removed from learn_config if you're making the (highly non-recommended) choice of starting learning prior to service startup.

What's wrong with that?

I too, am courious to understand why that is wrong.
If some day I figure it out myself, I'll post the explanation back here.

Starting it after the initial boot sequence means fewer permissions are required. Ideally, it's started as early as necessary to take effect before any security boundaries are necessary but no earlier. That's why there's the iptables integration, to prevent any connections from happening before RBAC is enabled.

Thanks, strcat!

It does add up! It certainly is so.