Quote:
|
Not exactly a reply to your thread, since you're on a different track, but I'd like to draw your attention to a short explanation of what Grsecurity can do for you wrt to restricting users, for instance denying setting up client or server sockets and other ramblings about the search for the "ZA for Linux" grail I've made in /sec earlier on.
|
Thanks for commenting on my post,
and the two very interesting/highly
informative links. I'll certainly give
grsecurity a try (hoping that it'll be
fine with the other custom kernel
patches, like ACPI ;})
Quote:
Quoted from the other rambling -thread
Scanning /proc will be more of a "brute force" approach because for instance starting up a client app like Nutscrape doesn't mean I'm going out on the network. Sniffing for traffic and denying it as soon as it doesn't match up with any criteria is just too late, so waiting for an app to make a call to set up a socket seems the best way so far. Having a static list of apps that are always allowed could speed up the decision part. Also for all of the above you have to ask yourself if an app could DoS this "ZA for Linux" approach.
|
I was thinking about a iptables pluggable
module that uses /proc to establish the PID
of the process making a connect, check the
application doing it against a database of
whatever kind (loading known & trusted apps
the first time the target is jumped to from a
config-file [Psql-database, XML, ...]), verify
the user running it, ... and prompt ruth while
denying unknown programs/people at first.
With the userland interface of iptables it
would be a breeze to kick out DoS by
handing them on to tcpwrapper :}
The hardest bit would be to make a client
for this approach that runs on win-boxen
on the network (so I can check their authenticity,
too, the Linux machines are less of a concern).
Cheers,
Tink
