problems in stage 2 with gradm

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

problems in stage 2 with gradm

Postby Construx » Sun Jul 07, 2013 4:44 pm

My distribution provides its own version of gradm, which I am trying to make use of, and its version is called gradm2. The command for it is at "/sbin/gradm2", and using it with only the "-h" options shows the same set of options as described online. However,

when I run this command if fails: gradm -F -L /etc/grsec/learning.logs

And the message is this: Could not open /dev/grsec2.

I looked for that file too, but it is not there. I do see this one, /dev/grsec, which I am inclined to think was put there when I compiled the patched kernel. Since the Debian distro uses gradm2, it would appear that it expects to find /dev/grsec2 as well, naturally. My first inclination is to just rename grsec to grsec2 and run with it, but I am not sure that is the best way to proceed here. Also, I am not sure whether other such renaming issues should now be made?

Any ideas would be welcome about this issue?

I should point out another issue that has arisen as a result of installing the Debian version of gradm2. In the procedure here for compiling gradm, the steps included a point where a password was to be created. Specifically,

"Finally, and most importantly, you will be asked to provide the administrative password for the RBAC system. Choose a long password, but one that you will remember (especially if you start gradm from an initscript). Do not use the same password as your root password."

Since my installation of the Debian version did not include creating a password, I now would need to make one. Not having one generated automatically ends up creating another issue in the enablement process, and one needs to be made manually to get started. I think this point should be highlighted in the instructions for future reference to help others save time.

Thanks.
Last edited by Construx on Mon Jul 08, 2013 10:41 am, edited 1 time in total.
Construx
 
Posts: 25
Joined: Tue Jul 02, 2013 7:27 pm

Re: problems in stage 2 with gradm

Postby spender » Mon Jul 08, 2013 7:49 am

I have no control over Debian's strange packaging of gradm or how updated it is. You'd probably be better off just downloading gradm from grsecurity.net, compiling with 'make' and installing it with 'make install'. It will handle the creation of /dev/grsec and the setup of administration passwords.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: problems in stage 2 with gradm

Postby Construx » Mon Jul 08, 2013 10:32 am

> "You'd probably be better off just downloading gradm from grsecurity.net, compiling with 'make' and installing it with 'make install'."

I have no problem with doing so. Actually, I am going to recompile another patched kernel patch as well because I found that the first instance of it, although successfully compiled with grsec, ended up breaking my ability to launch Virtualbox and, moreover, even broke my ability to make use of the X-window-system GUI environment. Before installing it, I was running the server remotely primarily from Xterm, and only occasionally would I need to start the GUI with "startx". After applying the kernel patch, neither startx nor Vbox would run. :cry:

I fiddled with them a bit, and things seemed to get worse, not better. :oops: So, since it was pretty much near the beginning of getting set up anyway, I decided to reinstall the whole shebang. That's done. Now I get to redo the patch thing and pick up where I left off. I don't know if there is anything I can do especially differently to avoid breaking it again, but I was wondering about a different approach. Two questions come to mind. First, I suppose there is no harm in preferring to make use of the very most recent kernel available for which you have made a patch rather than picking an arbitrary one? Secondly, I could be way wrong about this idea, but it seems to me that there are good arguments for preferring to apply the patched kernel "in the beginning" of a system configuration instead of waiting until a number of major programs (e.g., VirtualBox) has been installed. I say this because I am under the impression that during the installation of some, if not many, programs, the installation and configuration would actually depend on what is allowed by the kernel itself. Therefore, getting the kernel set up for the most part would be a good thing to have in place before trying to install programs. Otherwise, I end up with having to fix or reinstall programs after modifying the kernel. One thing is certainly clear, I am better off compiling gradm instead of using the repo's version despite the instruction to the contrary.

Can anyone share some thoughts about doing this process in one order or another?
Construx
 
Posts: 25
Joined: Tue Jul 02, 2013 7:27 pm


Return to grsecurity support

cron