Interactive Learning?

[dancebee]

I'd like to thank the grsecurity developers for a great package, and suggest a new feature to improve security and simplify administration.

While I think the ACL learn model is a great idea, I am concerned about the period of time when a new package (such as a daemon) is downloaded, built, and given an initial ACL learn run. During this time, the package is trusted, which is not necessarily a good thing. While grsecurity is watching its every move and reporting its behavior to the syslog as LEARNs, it is relatively unrestrained in what it can do (If I understand correctly how LEARN is implemented). Suppose it was trojaned, and starts installing its root kit. This could happen early, such as at ./configure, emerge, apt-get, or rpm time. Because package installation will likely need to be done with an admin role, the normal safeguards against trojans will be relaxed.

While I'm not sure if this has already been discussed or implemented, I would like to propose an "interactive learning" mode that works in a similar manner as web browsers do when they query users to see if they're interested in accepting a cookie from a particular web site.

When this mode is turned on (by role), any action by a process that would normally trigger a new LEARN rule being written to the syslog, instead blocks, while a confirmation request is sent to an interactive user-space app.

The user space app then queries the admin such as like this:

Process "ftpd" attempting to access "/etc/passwd" for read?
[1]Deny, [2]Kill, [3]Allow, [4]Allow and learn, [5]Allow class and learn.
?:

(1) would return an open failure to ftpd, but allow it to keep running
(2) would kill the process
(3) would allow the action on a one-time basis (but no LEARN record written)
(4) would allow the action multiple times and write a LEARN record
(5) would be like 4, except a larger class of things would be allowed and LEARNed. In the example above, all read access to /etc might be allowed.

I think this would be a great way of tightening up the security loophole opened up by the current non-interactive learn process, and would protect against trojans taking control when packages are installed by an admin role.

It would also solve the more general problem of getting linux-grsec up and running on a new system with minimal hassle, without having to preconfigure special exceptions for all the binaries which are problematic like xfree, java, etc. Having to the look at the syslog every time a program crashes, then needing to make a new ACL or running chpax is harder than it needs to be.

Such an interactive learning feature would also make it feasible for an administrator to never need to relax security with "gradm -a" because any need for relaxed security would be queried and approved on an as-needed basis.

Comments?

Thanks,
James

[Cyt0plas]

How about a #6: Deny and learn? (specifically remove that access, should the ACLs ever be opened up later).