[refpolicy] [PATCH v2 1/2] Support the console/graphical links browser

[Sven Vermeulen]

On Sun, Nov 13, 2011 at 10:48:50PM +1100, Russell Coker wrote:
> > When do you consider the need for separate domains and not? An earlier
> > discussion on nginx versus apache was in the direction of a separate domain
> > for nginx because it did some stuff that apache couldn't.
> 
> Most of the stuff that Apache and Nginx do are the same.  Having separate 
> policy will lead to more duplication of work.  If we want to protect web 
> servers from each other then I think we should do what we did ages ago with 
> SSH and have a template for the base functionality that is instantiated for 
> each one.

I can surely follow this. It would be great to have a template that
"upgrades" a domain towards being a browser-domain (i.e. user input, http(s)
access, ...) so that individual browsers can quickly be contained within
their own domain.

But that would probably mean that we define a "browser" module, and then
have links & mozilla work from that module.

> > Likewise, I can argue that the mozilla module does more than links, so why
> > use a much more elaborate policy for a small application?
> 
> Given that links is described as using an X display the amount of extra 
> functionality can't be that great.

I was referring to mozilla, which has a lot more privileges than links would
ever need (including plugin subdomains and such). However, links is also
used as a console browser, something that mozilla's browser would never
need.

Using a browser template in general would fix things to support the bare
minimum, but it would still give a separate domain for links imo.

I know this is often a matter of convenience and maintainability: where do
you put the line? You can have a generic domain for multiple applications
(like the games module), a one-on-one mapping (like for jabber) or multiple
domains for one application (like postfix).

I personally aim to have at least one domain per application, and where an
application has multiple different processes, use different domains for
those as well. But that does mean quite a lot of maintenance/management on
the policies. But if that can be simplified by having the appropriate
templates, that would be great.

Wkr,
	Sven Vermeulen