some grsec problems :)

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

some grsec problems :)

Postby wolfpaw » Mon Sep 22, 2003 10:52 am

Hi All,

I have a few questions about grsec, if anyone can comment, I'd be grateful:

A) Can you change the "lockout time" for the password retry lockout
without a reboot? It doesn't appear so, but I thought I'd ask.

B) The password lockout appears to affect all IP addresses once it
is done. It is a good idea, however, if a hacker obtains root, and runs
gradm with a bad password 3 times, it will lock us both out. Which means it limits my ability to deal with him. I would consider this a logic flaw, or
am I missing something? How should I deal with this?

C) Is there a way (I can't seem to find it) to set restrictions on a login ID other than simply putting those restrictions on thier home directory? It would seem to me that it would be available, but I must be missing it in the ACL documentation.

Great job on GRSEC guys :) We used a commercial product previously (Argus Pitbull LX), and I must say, I beleive your product surpasses thier functionality.

I could patch it for the above 2 things, but I thought I'd check to make sure I wasn't missing them somewhere first :)

Regards,
Dale.
wolfpaw
 
Posts: 9
Joined: Mon Sep 22, 2003 10:46 am

Postby spender » Mon Sep 22, 2003 1:41 pm

The lockout time cannot be changed without recompilation.

As for the other question, I don't consider it to be a logic flaw, since in many situations, it would be difficult/impossible to determine a real admin from an attacker (impossible if the case is the attacker compromised a trusted machine of yours which is the only IP that connects to the machine for admin access, difficult in every other case). I could implement a whitelist type system for it, but I think that would decrease security, as it assumes a trusted network.

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

Postby wolfpaw » Mon Sep 22, 2003 2:13 pm

Fair enough - so what should our response policy in such a situation be? Most the machines, while accessible from the server room via console, are administered remotely from 15 min away. Just trying to find a solution to that kind of problem. Is there a way to restrict what IP adderess can even use gradm or something such as that, to at least decrease the likelyhood of something like this occuring? As it stands (at least as I understand it) anyone comprimising something and getting root can play with gradm.

Also - did you have any ideas on the "per user" limiting, other then using an ACL on the home directory?

Thanks Brad :)
D.
wolfpaw
 
Posts: 9
Joined: Mon Sep 22, 2003 10:46 am

Postby spender » Mon Sep 22, 2003 3:27 pm

As for the user thing, if you want to have different ACLs for different users, grsecurity 2.0 does exactly that.

In grsecurity 2.0, you can restrict certain roles to certain IPs, so you could restrict access to gradm that way.

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

Postby wolfpaw » Mon Sep 22, 2003 3:34 pm

Kickass :)

When's it out? Can I help in some way? :)

D.
wolfpaw
 
Posts: 9
Joined: Mon Sep 22, 2003 10:46 am

Postby spender » Mon Sep 22, 2003 3:50 pm

2.0-rc3 is on the download page. It contains the features I was just talking about. The final release will different only in algorithm enhancements (most likely).

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

Postby wolfpaw » Mon Sep 22, 2003 5:27 pm

So 2.0 is stable for production? I had heard it was not yet..

Just want to confirm :)

Thanks Brad :)
D.
wolfpaw
 
Posts: 9
Joined: Mon Sep 22, 2003 10:46 am

Postby Incognito » Sun Nov 16, 2003 5:26 am

Wanted to know this too. I see its an RC3 but how many known bugs are still left?
Incognito
 
Posts: 11
Joined: Sat May 10, 2003 7:53 pm


Return to grsecurity support

cron