[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFE: FireKit



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]