Well it can be handed off to a "root" process via dbus which imposes all the necessary security. We don't want to make this an install time option, especially for peer services like BT. You don't want a static firewall rule for a process that is only running occasionally. No, what you want is an appropriate firewall rule set only for the time that BT is actually running. Anything else is a security risk in itself.
Actually, when you're talking about processes on the local machine, firewall rules are a totally hackish way of going about this.
What you want to do, is have some kind of local ACL that says what processes and users can bind to what ports. This would solve a whole mess of security problems. (Look around, a great many server daemons have to be started as root, for the mere fact they want to bind to ports <1024.) Instead of firewalling, make the kernel disallow processes from even binding listen ports at all in the first place.
I know back when I was playing with grsecurity years ago, it had a feature like this. It had group-based access control, you could set up a certain group and say "This group can not bind listen ports" and even "This group can't make outgoing connections" too. Or you could turn it around and say "Only this group can bind to ports" etc.
It had some weird side effects though. IIRC various things wanted to bind to loopback...
Can selinux do this? If not, it should.
On Sat, December 17, 2005 3:12 pm, Callum Lerwick said:
Actually, when you're talking about processes on the local machine, firewall rules are a totally hackish way of going about this.
What you want to do, is have some kind of local ACL that says what processes and users can bind to what ports. This would solve a whole mess of security problems. (Look around, a great many server daemons have to be started as root, for the mere fact they want to bind to ports <1024.) Instead of firewalling, make the kernel disallow processes from even binding listen ports at all in the first place.
Yes, I believe ports are given a security context as well, although I don't know how fine grained it is or if you still have to deal with iptables rules in addition.
Sean
I know back when I was playing with grsecurity years ago, it had a feature like this. It had group-based access control, you could set up a certain group and say "This group can not bind listen ports" and even "This group can't make outgoing connections" too. Or you could turn it around and say "Only this group can bind to ports" etc.
It had some weird side effects though. IIRC various things wanted to bind to loopback...
On Sat, 2005-12-17 at 12:12, Callum Lerwick wrote:
Actually, when you're talking about processes on the local machine, firewall rules are a totally hackish way of going about this.
Actually it's having to dynamically alter your policy, because of the weakness of it's expression that is hacky. Between selinux and netfilter you should be able to precisely state your policy.
The only thing is his UPnP nternet Gateway Device (IGD) controller via Dbus should be a userland process and this deputy should be able to inspect the selinux domain of the requesting process and based it's decisions on that as well.
What you want to do, is have some kind of local ACL that says what processes and users can bind to what ports.
Can selinux do this? If not, it should.
In theory yes, of course some people are disabling even the targeted policy and the strict policy might not yet be ready for primetime. You'd need the strict policy if you don't want most user's processes running as unconfined_t .
How is the work on getting strict policy working well going anyway?
http://www.netfilter.org/ http://www.nsa.gov/selinux/ http://selinux.sourceforge.net/
http://www.knoxscape.com/Upnp/NAT.htm http://www.microsoft.com/technet/prodtechnol/winxppro/support/upnp01.mspx http://en.wikipedia.org/wiki/Internet_Gateway_Device http://www.upnp.org/standardizeddcps/igd.asp