I sat down last night with some old tech (pen and paper) and plotted out a course that would involve being able to configure ACLs that are to be present in ipf.conf and allow fine grain control over who can do what.
At present I'm even thinking of going so far as to allow root to configure ipf such that root can't add/remove rules or the ACLs or disable (unload) IPFilter. Thus for a system that had booted, enabled ipfilter and started running, you could make the only way to "stop it" be a shutdown. That's quite impractical for common use, but I can envisage some people seeing it as desirable. Darren Darren J Moffat wrote: > Based on your description of what you are trying to do I think you > want an ACL based system for some of this rather than privileges. > > The reason I think that is your comment about certain subjects only > being able to remove the object changes they put in place. > > Why an ACL rather than a privilege or authorisation ? > > Authorisations are purely a userland concept and are usually used by > privileged userland apps to control wither or not they use their > privilege or perform some other sensitive operation. > > With an ACL you can express exactly which operations a given subject > or set of subjects can do to a given object. > > In the general case rather than the specific case of firewall rules > the sys_net_config privilege really does need to be broken up, even > more so now that we have stack instances and vncs etc. Though again > privileges might not be the only thing we need. > > Depending on the exact needs of the firewall rules case there could be > a use for a PAGs (see the recent thread that Nico Williams started) > approach to rules. For example the rules to open up a given port are > only valid while there are processes left in the PAG that added the > rules, once they are all gone the rules should be automatically reaped. > > In some ways type enforcement (the FMAC project for example) could be > more appropriate here but we have to be very careful of the possible > rule complexity that could bring along with it. It could solve the > problems but could also just create a new set instead by making the > rules too flexible and thus to confusing to the end admin/app developer. > > A simpler case might be to use what the FGAP project provides (note > that some of this has already integrated). This is a more natural > extension of the privilege system so that more specific rules can be > applied when a process *lacks* the privilege necessary to do the job. > > -- > Darren J Moffat
