> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
