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.