# Gradm Initialization Questions

## anyNiXwilldo

1. Does gradm need one password or two? I ask because of the following found in TFM:

The installation process does the following.......you will be asked to provide the administrative password for the RBAC system.

The above is all well and good, but I don't recall being asked for a password when I emerged gradm. I also do not know if gradm requires a separate additional password for the admin role.

2. TFM also states, on the same page linked above:

"Do not perform any administrative tasks outside of the admin role while full system learning is enabled."

Does this mean I can't log in as root while in learning mode? Do I need to disable my daily crons (which require root access) while learning mode is enabled? 

My system is already built as hardened and I have run it for a few months now. I am only now sure enough of the system to enable gradm. I just don't want to end up locked out of my system once the learning mode is complete. I also don't want to mess up learning mode if I shouldn't be doing root tasks when learning mode is enabled. I did remove my normal user account from the wheel group prior to installing gradm. The documentation isn't very clear to me, but I am really looking forward to putting the finishing touches on my desktop.

Any help is appreciated.

----------

## cach0rr0

this explains the password bit:

http://www.gentoo.org/proj/en/hardened/grsecurity.xml

(down under RBAC section)

you have your normal unix users (root, normal user, etc)

and then the point it's trying to make is that the password for gradm is *separate* from all that; as in, gradm uses a separate password. So, it's the one and only gradm password, but it's an additional password you need to remember; whether that's 1 or 2 depends on the perspective of the reader. 

to your second point, while it's "learning", nothing should be blocked/denied/whatever. What will happen if you don't adhere to this:

 *the dox wrote:*   

> 
> 
> Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate of any other heavy file i/o operation as this can really slow down the processing time.
> 
> When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under /etc/grsec/learning.roles
> ...

 

is that learning.log will end up with a crapton of meaningless chatter, that will then be converted to policy. Some of it may even be counter-productive. Meaning, when you go to review the learning.roles that are generated from learning.log you have loads more cruft to sift through.

----------

## anyNiXwilldo

 *cach0rr0 wrote:*   

> this explains the password bit:
> 
> http://www.gentoo.org/proj/en/hardened/grsecurity.xml
> 
> (down under RBAC section).

 

DOH! Talk about missing the obvious. I should have gone to the Gentoo Docs first, before the Grsecurity docs.

 *cach0rr0 wrote:*   

> 
> 
> you have your normal unix users (root, normal user, etc)
> 
> and then the point it's trying to make is that the password for gradm is *separate* from all that; as in, gradm uses a separate password. So, it's the one and only gradm password, but it's an additional password you need to remember; whether that's 1 or 2 depends on the perspective of the reader. 

 

I thought there might be one password for gradm and then a second password for the gradm admin role. 

 *cach0rr0 wrote:*   

> 
> 
>  *the dox wrote:*   
> 
> Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate of any other heavy file i/o operation as this can really slow down the processing time.  

 

Ok, I think I've got it. I can comment out (prior to enabling learning mode) the two crontab entries I have for eix-sync and eclean, assuming eclean involves heavy file i/o.

 *cach0rr0 wrote:*   

> 
> 
>  *the dox wrote:*   
> 
> When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under /etc/grsec/learning.roles
> ...

 

So we want enough learning to get the job done, but not for too long of a time period to avoid too much chatter. Do I need to open every binary on the menu while in learning mode to gain permissions to all apps as a user once learning mode is complete? 

 *cach0rr0 wrote:*   

> 
> 
> Meaning, when you go to review the learning.roles that are generated from learning.log you have loads more cruft to sift through.

 

HA! I am SO green in this. I don't know if I would even understand what I am looking at in my 'review.' I know you know what you are talking about, because I've seen posts of yours about hardened going back for years. Is it crazy to do this on a KDE desktop, even if only for curiosity? And thanks for your help. I am exceedingly curious about this and have had almost no issues with running a KDE desktop on hardened gentoo.

----------

## cach0rr0

 *anyNiXwilldo wrote:*   

> 
> 
> Ok, I think I've got it. I can comment out (prior to enabling learning mode) the two crontab entries I have for eix-sync and eclean, assuming eclean involves heavy file i/o.
> 
> ....
> ...

 

I don't normally do this on a desktop to be honest. It's a good idea if you can pull it off, but it *is* more work. Whereas a server has 1 or 2 specific purposes, and it may have just say, apache, serving up files, occasionally people logging in via SSH, etc, these are going to generate a smaller set of log entries, so the ruleset will be much smaller. 

For a desktop, that serves dozens of different purposes, app A accesses host 3 on port 8080, app B accesses host 2 on port 3128

 *anyNiXwilldo wrote:*   

> HA! I am SO green in this. I don't know if I would even understand what I am looking at in my 'review.' I know you know what you are talking about, because I've seen posts of yours about hardened going back for years. Is it crazy to do this on a KDE desktop, even if only for curiosity? And thanks for your help. I am exceedingly curious about this and have had almost no issues with running a KDE desktop on hardened gentoo.

 

gradm rules are so supremely subjective there really isn't an alternative except for, look at the resultant rules, then compare them to the *official* gradm (read: "not gentoo") documentation on rules, to see what they do. 

In your case I would do the learning process twice. 

The first time, I would just use your *usual* apps a bit to get the logs generated. Save this log. 

The second time, I might be inclined to click through more apps on the menu, and thus generate more logging data. 

What that will do is this: if, when using the first ruleset, too many things are blocked, you can go in to the second, see if those same things are blocked, then compare the two policy sets side by side. 

it's not a quick process. There is a fair bit of reading on gradm rule syntax you have to do, a lot of trial, error, disable gradm, trial, error, repeat. If you manage to stick with rbac on a desktop, kudos - i sincerely wish i had the patience, but i do not. Wish i did. Don't. I think it's worth it, but I haven't the time. 

About the only shortcut you'll find in the process, is that learning mode will log individual binaries and every file that they access, so on and so forth. The subsequent generated policy will include all of that as well. You will find certain apps can be allowed to, instead of just accessing individual files, access entire directories. For example, with apache, i dont need to have a rule stating every single file it can access, i can have one rule that allows apache to access anything under my DocumentRoot directory, one rule to access the directory containing any of the files it uses for its handful of modules. I don't need to specify every file it can access! 

That's the level of control you have with gradm/rbac. And with it, comes the ability to take variable length leaps inasmuch as locking down your system goes. Once you DO understand its syntax, it's far more intuitive to maintain and write rules than say, SELinux (*cough* garbage *cough*), though SELinux does have a handful of pre-canned policies (again, SELinux sucks, avoid). 

The bright side? Your actual production/daily-use policies do NOT have to be as lengthy or verbose as the ones generated from the learning.log. You should use learning.roles as a starting point to hack at, a template of sorts, to use to create your own policy - which will ultimately likely be far smaller than learning.roles

HTH - you've got a bit of reading in your future!

----------

## anyNiXwilldo

Alrighty. I set the gradm password and the system is in learning mode now. I did also have to set a password for the shutdown role, but used the same password that I set for gradm.

----------

## anyNiXwilldo

Gee, if only the learning logs were a bit more detailed.HAHA!

I think this will be workable. I converted the learning.logs into learning.roles then converted those into policy. Once of the first things I noticed is, I can't download anything to my /home/username folder. So I gradm -D, then copied the policy file to my home and chown to my user. This is the line I think I am looking for:

/home/username			r

So I am guessing that means my /home/username folder is set read only, which I can easily change in the policy file to rw.

----------

## anyNiXwilldo

 *cach0rr0 wrote:*   

> 
> 
> There is a fair bit of reading on gradm rule syntax you have to do, a lot of trial, error, disable gradm, trial, error, repeat. 

 

The policy file itself makes it fairly obvious. It really didn't take much tweaking to get it like I wanted. The main issue was with kmail, but that is solved. 

Grsecurity and gradm are absolutely brilliant. They SHOULD be the default on every distro. I'll never go back to standard Gentoo. Hardened IS for the desktop.

----------

## cach0rr0

 *anyNiXwilldo wrote:*   

> 
> 
> Grsecurity and gradm are absolutely brilliant. They SHOULD be the default on every distro. I'll never go back to standard Gentoo. Hardened IS for the desktop.

 

yip. grsec's exclusion from mainline is more political than technical - lots of toes belonging to folks with big egos stepped on by grsec. But grsec rocks. 

hardened does very nicely unless you use a binary package or binary kernel blob. If you're building everything yourself, it's cake. 

IMHO - selinux needs all of those pre-canned policies, because selinux syntax is hideous. grsec is very intuitive, but "one size fits all" doesnt really work as well. At least not with source distros. 

either way, glad you figured it out, happy gentooing! More patience than I have, only roughly half of my hardened boxen use grsec RBAC.

----------

## anyNiXwilldo

It didn't really take that much to get it working. I think it's most important to use the learning mode and open every app installed. That's roughly 40 on my machine. Other than that, I set my home folder rwcd in the policy. I set qbittorrent role rwcd on the Torrents folder. That was pretty much it. The policy file is so clear and easy to understand, it's very easy to set as you need. 

My only remaining issue is where, in the boot process, to enable gradm. If it is put in rc.local, kdm can't load. I am thinking maybe sleep for 5 minutes in rc.local, then gradm -E.

----------

