On Sat, 2005-12-17 at 07:41 -0500, Sean wrote:
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.
Oh I see what you are saying. When trusted application foo is being run by user in trusted group bar (or open for any user) - the firewall will open ports xxxx to yyyy should foo request they be opened - for the duration that foo is running.
That would be slick.
On Sat, December 17, 2005 10:53 am, Michael A. Peters said:
Oh I see what you are saying. When trusted application foo is being run by user in trusted group bar (or open for any user) - the firewall will open ports xxxx to yyyy should foo request they be opened - for the duration that foo is running.
That would be slick.
Yeah, you said more clearly than what i muddled out. Somewhere in the mix a policy could be set to force the user to agree/cancel or enter a password (perhaps just on the first invocation). If this dynamic-firewall service became common most network apps could be updated to use it. Hopefully it would make things easier for the casual user with a simple setup.
Ultimately the dynamic-firewall service could even have an option to do UPnP or zeroconf too, and thus enable auto-port-forwarding for any app (if desired).
Wouldn't surprise me to find out that someone is already working on something like this though.
Sean
On Sat, 2005-12-17 at 07:53, Michael A. Peters wrote:
On Sat, 2005-12-17 at 07:41 -0500, Sean wrote:
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 shouldn't the strict selinux policy cover this type of thing much better. Not only just while BT is running, but only BT the app can listen on that port range?
Oh I see what you are saying. When trusted application foo is being run by user in trusted group bar (or open for any user) - the firewall will open ports xxxx to yyyy should foo request they be opened - for the duration that foo is running.
yes and that request should just be the bind(sockfd, my_addr, addrlen); The kernel should be able to decide to grant that request based on the information it has being a "trusted" app(selinux context label), run by trusted user(uid,gid,selinux domain).
That would be slick.
It would be slicker if only the BT app could use those ports and you didn't have to dynamically punch holes in the firewall.
On Sat, December 17, 2005 3:28 pm, Stephen Pollei said:
That would be slick.
It would be slicker if only the BT app could use those ports and you didn't have to dynamically punch holes in the firewall.
Yes, but you may have to punch holes in the firewall _as well_. I don't think selinux security context would override any local firewall rules which (as they stand today) lock down all ports that aren't explicitly enabled for a service.
Sean
Michael A. Peters wrote:
Oh I see what you are saying. When trusted application foo is being run by user in trusted group bar (or open for any user) - the firewall will open ports xxxx to yyyy should foo request they be opened - for the duration that foo is running.
That would be slick.
Overall, that kind of thinking is what it's going to take to use SELinux to get real security improvements over standard Linux for processes that are run by everyday users... We'll need some kind of "security manager" where root can tick off what kind of actions that root wants to allow ordinary users to do.
-
Michael A. Peters -
Paul A Houle -
Sean -
Stephen Pollei