> > Nice, you probably want to keep the application/kernel tag name spaces
> > distinct though. Otherwise it would be easy for any local user/program
> > to mess with pf.conf generated tags and bypass filtering etc. It could
> > be as easy as adding a prefix ("APP_" ?) to all application generated
> > tags.
> >
> >
> > Can
> >
>
> I'm not sure if this is necessary. If a user tag his pakets via
> pf.conf there is no need, so why should it be diffrent via
> socketoption. However, should be there a reasson, I would recommend to
> do this with kernel-tags ("KERNEL_"), or to mention a recommendation
> for setting tags via setsockopt with (for example "APP_").
> If I'm wrong with my thoughts, its not to hard to change that. :)
Changing pf.conf and setting/changing the filter in the kernel
requires root permissions. Therefore, only users/processes with root
privileges can modify the rules and change the tagging/filtering
policy. Setting a socket option does not require a privilege. Any user
or process can do it. If they mistakenly or deliberately set the same
tags specified in pf.conf they could potentially mess with the
filtering policy of the box, and may be able to bypass some
restrictions that are set against them in pf.conf.
To be more clear, if the user/application sets the tag to "MYTAG" with
setsockopt, it should be reflected to pf and filter rules as
APP_MYTAG. The prefix to use is obviously open to discussion (what
about @MYTAG).
I am not sure how you could to change the 'kernel' tag names and
become transparent/compatible at the same time. Since this is a new
feature, it should make every effort to not break existing
configurations and rulesets.
Can
--
"Who is tagging the taggers?"
