RFE: FireKit

[Matthew Woehlke]

Adam Williamson wrote:
> On Thu, 2009-07-23 at 17:17 -0500, Matthew Woehlke wrote:
>> I have to ask... when are we going to see Linux allow network access 
>> based on the checksum of the process that wants to use it? After all, 
>> 'doze has  had this ability for years. (Maybe SELinux can provide this 
>> already?)
> 
> It's probably a good thing we didn't do this a few years ago. With md5
> checksums. ;)

Not really; checksums just provide an additional layer of security above 
the process name (or better, full path, which means root-owned are 
already pretty well protected without the checksum). Besides *any* form 
of per-process permissions would be more than we have now.

Although checksumming isn't needed if you do it via SELinux contexts in 
a way that you can't accidentally set a context, and any change to a 
binary causes the context to be dropped. (This is probably better 
because a: you rely on the OS to drop the context on /any/ change, so 
there is no checksum that can be spoofed, and b: you can trust the 
package manager to assign contexts, which results in less maintenance 
since updates via the PM don't require updating checksums.)

(And I realize that I am pretty sure SELinux doesn't provide real 
per-process security; maybe for listening, but for outbound, a good 
per-process firewall can restrict what addresses a process can talk to. 
I don't think SELinux can do this? And if it can, it is certainly 
wandering very badly into iptables' territory.)

I guess one way to do this would be to (maybe using SELinux?) toss 
sockets opened by a process (identified by full path and checksum) onto 
a specified iptables chain rather than the default OUTPUT. This would 
require the least changes to iptables, and is roughly what Tiny 
(Windows, best firewall I've encountered yet in terms of function) does.

INPUT unfortunately must be done differently since you are blocking 
above the socket layer. Besides the ability to make temporary holes 
(which I like), I think the best thing would be to have an iptables rule 
that allows stuff if there is a socket that will receive it, otherwise 
can drop (if you don't drop, you're just using 'allow' permanently and 
letting the OS handle the close notification). Then use SELinux or 
something similar to control if a process is allowed to open listen 
sockets in the first place.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"unsubscribe me plz!!" -- Newbies