On Wed, Jan 21, 2009 at 5:25 PM, Rob Meijer <capibara@xxxxxxxxx> wrote: > On Wed, January 21, 2009 02:18, Casey Schaufler wrote: >> >>> we don't need this at all, as we are in process context, syscall can >>> sleep. >>> Trust me, it's strange to have it's web browser freezing waiting for a >>> timeout if the userspace part doesn't reply, but if it's replying, it's >>> transparent. >> >> I hate to be the one to say this, but it looks to me as if the >> easiest way to solve the problems that you have outlined would >> be to create a new LSM based on SELinux with two important >> changes. The first would be to have a separate policy for each >> user (or process tree) and the second would be to make the policy >> specification discretionary. SELinux has all the mechanism you're >> talking about, but you want the policy being enforced to reflect >> a set of "personal firewall" rules rather than "domain type" rules. >> From the lobby at LCA in Hobart these rule sets are pretty hard to >> tell apart. And let's not have the "SELinux isn't designed to do >> that" row. Of course it isn't. Nonetheless, the personal firewall >> sure sounds a lot like SELinux if you ignore the MAC/DAC difference. > > I think this is a perfect example of where using MAC 'and' DAC or rather > centrally 'and' user managed profiles would be very fruitful. If you can > create a purely permissive centrally managed per user profile, in fact > delegating a permission set and allow each user to decompose and > discretionary delegate parts of this profile to programs run by this same > user, but with MAC restrictions when delegating to a process run by a > different user, you would IMHO have a very powerful combination of MAC and > DAC. > > I'm not sure however a label based MAC system would be best suited for > combining MAC and DAC in such a way. > > > I really don't see the need for special here other than improving iptables. LSM module is over kill. This leads to double processing of packet requests. netfilter already can operate as either MAC or DAC all depending on the rules passed into it and the outside LSM applied. selinux and other lsm's can stop applications from changing the netfilter. So basic filtering of what can be changed in iptables basically turns iptables from a DAC to a MAC. Advantage added no more layors for network packets to go though. Only cost for outgoing really is changing the rules. Once rules are set cost compare to normal disappears. Yes there will be a cost on incoming since application level incoming filtering is not done at the moment. There is a major problem here for tuxguardian idea of being at the application API interface how in heck are you going to block something before it has to travel all the way threw the net-filter stack. [network card]-[netfilter]-[applicaiton] Idea makes it [network card]-[netfilter]-[application filter]-[application] Really a bad outcome. If user say on X port they don't want traffic from X IP but they want to let other IP's tuxguardian still has to netfilter so its stoped soon enough. No point processing items you are just dropping. Netfilter can already reject or approve out going packets from applications on the base of user id process id and so on. This is before packets enter the Netfilter processing stack. Cost of looking up if applicaiton is approved or not appoved is out weight be the cost of rejected packets going trough netfilter. Sorry netfilter is already sorting out how sockets can be used. What you are basically talking about is two layors doing exactly the same thing. Half of what tuxguardian does can be done in a iptables module. Ie filtering out going traffic based on application. Please explain why expanding netfilter is not a option. Expanding netfilter avoids conflicts with LSM's. Filtering traffic coming into applications is missing. I am also sorry tuxguardian over looks something using i7filter would allow applications to share the same port number or block invalid type packets being sent to an application. True solid home firewall solution really should be able to use i7filtering where needed. Same with multi user-support. The idea that personal firewall does not need to filter packets is foolish. Also the idea that machines that are always single user exist is also foolish. More and more Linux distributions are supporting user switching. Linux is completely designed as an multi user OS. So design need to take that into account. Peter Dolding -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
