On Oct 24 2007 19:59, Simon Arlott wrote: >On 24/10/07 19:51, Jan Engelhardt wrote: >> On Oct 24 2007 19:11, Simon Arlott wrote: >>> >>>* (I've got a list of access rules which are scanned in order until one of >>>them matches, and an array of one bit for every port for per-port default >>>allow/deny - although the latter could be removed. >>>http://svn.lp0.eu/simon/portac/trunk/) >> >> Besides the 'feature' of inhibiting port binding, >> is not this task of blocking connections something for a firewall? > >The firewall blocks incoming connections where appropriate, yes, but it >doesn't stop one user binding to a port that another user expected to be able >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports >below 1024 and it's useful to be able to prevent users from binding to them >too.
Indeed. There has been a feature in the security framework that probably did not get much attention. It looks like YAGNI first, but on a closer look, it becomes useful pretty quick - secondary_register. As more and more simple LSM plugins pop up, stacking/chaining by means of secondary_register becomes attractive again, especially if these LSMs target different actions. This is probably the most useful thing why the LSM interface should remain modular: # Secure my files modprobe apparmor # -*- assuming apparmor implemented secondaries -*- # Secure my ports modprobe portac # More rights to users modprobe multiadm # -*- whatever else comes along -*- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
