ip / interface restrictions for users?

Discuss and suggest new grsecurity features

ip / interface restrictions for users?

Postby smith » Thu Apr 25, 2002 3:54 am

hello
first i've to thank the developers for their great work... i'm using the grsecurity patches on nearly every system ... :-)

but i'm missing one feature in grsecurity..
i'd like control on which ip which user can open which port, and i'd like to control from which ip addresses the user can connect to other systems on the net..

a aclsystem for tcp/ip(v4&v6) would be a nice thing...

smith
smith
 
Posts: 6
Joined: Thu Apr 25, 2002 3:30 am

Features

Postby michaeld » Fri Apr 26, 2002 3:13 am

Brad and I have already planned to add both user(uid/gid)
and process restrictions with regard to port/ip binding in grsecurity 2.0 =) Hope I helped

Michael
michaeld
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am

Re: Features

Postby smith » Fri Apr 26, 2002 5:12 am

:D nice nice...

are there any -devs that are avaible for tesing yet? :)

smith
smith
 
Posts: 6
Joined: Thu Apr 25, 2002 3:30 am

Postby spender » Fri Apr 26, 2002 11:22 am

well...the newest version out right now is 1.9.5-pre3. We can't release another -pre until the acl system is out of it's broken state (the userspace portion is virtually finished (check out http://grsecurity.net/cgi-bin/cvsweb.cgi/gradm , just need to write the kernel handling for the new parsing via userspace)

Lots of nifty things I've done with gradm:

1) duplicate process subject, process object checking
2) notification of an inexistent file/directory in ACL
3) notification when /lib, /etc/grsec, /boot, and /etc/rc.d are not protected
4) full include directive recursion that supports both relative and absolute filenames and directory names for acl configs
5) auto-add ACLs for libraries and the binary itself for process subjects
6) gradm can be placed in any location. via readlink on /proc/getpid()/exe, it determines the full pathname that it was executed as, and we add an acl for that path to be used with the auth mode
7) 128 bits of salt for passwords. Not incredibly necessary, but ensures that a dictionary attack with a prehashed list of passwords could not be used (would take a 1.2 TERABYTE sized file)
8 ) Very understandable code...I've tried to make functions out of most everything, so that the higher level operations read more like english. All important variables and functions are fully commented.
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Changes

Postby michaeld » Fri Apr 26, 2002 4:05 pm

Stuff I've done

-Offloaded a lot of the config file parsing onto brad
(ha! part of my master plan), increasing efficiency
because the kernel does less work...and simplifying
the searching/sorting because userspace can do more robust
parsing using lex/yacc

-Merged process/file acls. Performance benefits.

-Added time restricted acls

-Fixed a few minor bugs
michaeld
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am


Return to grsecurity development