All of lore.kernel.org
 help / color / mirror / Atom feed
From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH v2 1/2] Support the console/graphical links browser
Date: Sun, 13 Nov 2011 19:56:56 +0100	[thread overview]
Message-ID: <20111113185656.GA17129@siphos.be> (raw)
In-Reply-To: <201111132248.50639.russell@coker.com.au>

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

  reply	other threads:[~2011-11-13 18:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-13  9:37 [refpolicy] [PATCH v2 0/2] Add links_t domain for the links browser Sven Vermeulen
2011-11-13  9:37 ` [refpolicy] [PATCH v2 1/2] Support the console/graphical " Sven Vermeulen
2011-11-13 10:12   ` Russell Coker
2011-11-13 11:12     ` Sven Vermeulen
2011-11-13 11:48       ` Russell Coker
2011-11-13 18:56         ` Sven Vermeulen [this message]
2011-11-13  9:38 ` [refpolicy] [PATCH v2 2/2] Allow user domains to call links Sven Vermeulen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111113185656.GA17129@siphos.be \
    --to=sven.vermeulen@siphos.be \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.