Some questions concerning RBAC and full system learning

[wopp]

Hi,

I set up a grsecurity 1 system some 10 years ago, and now I'm finally getting a chance to familiarize myself with grsecurity2. I'm surprised that I find far less and mostly rather old apparently relevant hits when googling grsecurity issues (maybe I'm doing something wrong by searching for the wrong phrases, maybe many other people are doing something wrong by not using grsecurity ;-)).

I've got rather many questions, but I'll try to start with a few ones that I can put into (hopefully) clear words and work out some of the others on my own from there and then summarize or discuss my findings as appropriate.

What I've done so far with grsecurity2:

• Installed Debian wheezy, patched a vanilla 3.2.21 kernel with the patch from the Debian repository (2.9.1+3.2.21-201206221855-1), gradm2 also from Debian
• Some experiments in full system learning, manual policy configuration, learn_config modification
• Wondered about the naming mess Debian gradm2 introduces (/etc/grsec2 alongside an empty /etc/grsec; /dev/grsec2 used by gradm, though udev creates /dev/grsec, because that is the name the kernel propagates; /sbin/gradm2 as opposed to /sbin/gradm_pam). All in all a file name completion nightmare :-). I'm not sure I want to find out whether the "G" role flag or the "a" subject mode work correctly ...
• Restarted with vanilla 3.2.51, kernel patch 2.9.1-3.2.51-201309181906 and gradm 2.9.1-201309161709 from here. Feels much more sane.
• Built my own gradm2 deb with help of the Debian package source (and the new upstream gradm source, obviously) by dropping the name messing patch and adjusting the other patches.
• More learning experiments.

My questions for the moment are:

1. Do the contents of /etc/grsec/policy have any influence on the results of full system learning, or is the file simply ignored?
2. Does /etc/grsec/learn_config influence the generation of the log file by grlearn, or can I re-run gradm -F -L ... -O ... after changing learn_config without any new learning in between?
   My guess is that at least some changes to learn_config would require re-learning, but I'm not really sure if and which ones.
3. When are accesses put into the default subject by full system learning? How can I prevent that?
   My use case is a firewall, so I have some services running, and no normal user activity whatsoever. It's perfectly acceptable for root not to have any access at all except to gradm to change to one of several roles, according to the administrative task at hand.
4. I seem to have found out that a setuid system call (well, something in the course of a sudo invocation, to be exact) leads not only to a role change (to the new user role) but also to the i object mode (originally given to the sudo object) being lost, i.e. after the UID change the process no longer seems to have the inherited ACL. Is this correct? Is it intentional? ;-) Is there a way to prevent it? (I don't really need to, just checking my options.)

I'd be grateful for any explanation or for pointers to existing documentation on these issues I might have missed.

Regards,
Holger

[spender]

Hi,

Thanks for your patience -- I'm back from H2HC and responding as promised

Don't use the Debian grsec or gradm, it's horribly out of date as you can see by the naming (2012 06/22 -- over a year old).

To answer the other questions:

1) /etc/grsec/policy is completely ignored for full learning

2) /etc/grsec/learn_config can influence the generation of the log file for some specific rules, specifically the ones that force inherit-learn and always-reduce rules that reduce the size of the log by reducing certain paths down to a base path before they're written to disk. Outside of these two things, the influence of learn_config should only be in the generation of policies from the existing logs.

3) When they're not deemed "protected" resources via learn_config -- you can specify a path to be sensitive for reads, or sensitive for writes:

Code: Select all

#protected-path specifies a path on your system that is considered an
#important resource.  Any process that modifies one of these paths
#is given its own subject in the learning process, facilitating
#a secure policy.
#
#read-protected-path specifies a path on your system that contains
#sensitive information.  Any process that reads one of these paths is
#given its own subject in the learning process, facilitating a secure
#policy.
#
#high-protected-path specifies a path that should be hidden from
#all processes but those that access it directly.  It is recommended
#to use highly sensitive files for this command.


4) That's correct. Subject inheritance is ignored if a role transition is involved. It's something I can revisit later if there's a good use case for it behaving as you suggest, but I've never needed it to behave in that way in my policies and it'd change expected behavior.

Documentation-wise, there's just the comments in the policy and learn_config files, the RBAC Tutorial in the "papers" section of the site, and the Wiki.

-Brad