All of lore.kernel.org
 help / color / mirror / Atom feed
From: domg472@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] new policy: rtorrent
Date: Fri, 17 Jul 2009 11:58:50 +0200	[thread overview]
Message-ID: <1247824730.19628.12.camel@notebook2.grift.internal> (raw)
In-Reply-To: <20090717090925.GA1884@squirrel.roonstrasse.net>

On Fri, 2009-07-17 at 11:09 +0200, Max Kellermann wrote:
> On 2009/07/09 14:21, Dominick Grift <domg472@gmail.com> wrote:
> > On Thu, 2009-07-09 at 11:58 +0200, Max Kellermann wrote:
> > > Hi,
> > > 
> > > I have written a policy for rtorrent a while ago, and I thought it
> > > might be a good idea to submit it to the refpolicy project.  Here it
> > > is.
> > > 
> > > The policy defines the rtorrent_data_t type, but does not declare a
> > > fcontext for it.  Users who want to use it have to manually tag the
> > > data directory.  Another idea might be to provide a "reasonable"
> > > default...  on my machine, that's declared in the host specific policy
> > > .fc file.
> > 
> > Here is my take on the policy:
> 
> > allow rtorrent_t self:netlink_route_socket create_stream_socket_perms;

I suspect that it requires this. I might be wrong.

> Why this?  I had a "dontaudit" there.
> 
> > # semanage port -a -t bittorrent_port_t 6881:6999
> > # This type should be declared in kernel/corenetwork.te.in
> 
> Do we have to add 119 network_port() arguments there?  That's what the
> xserver line suggests.  Are ranges allowed?

Good point, maybe it supports ranges. But one or more of the ports in
range 6881:6999 probably conflicts with other services..

Bittorrent docs say it needs 6881 to 6999


> > files_read_etc_files(rtorrent_t)
> 
> Works without this line on my machines, although it fails to read
> /etc/nsswitch.conf.  I believe etc_t is too wide, because nearly every
> application needs read access; etc_t should be split further.

That is going to be mayor surgery as many existing domains needs access
to it. You would have to edit all those.

If you want to create policy conform upstream then keep it etc_t and
allow your domain access to it.

> You removed lots of explaining comments from my policy.  Why?

Many of those comments were obvious to me. But also because i like to
keep policy as simple/clean as possible.

not like this for example:

# rtorrent log file
type rtorrent_log_t;
logging_log_file(rtorrent_log_t)

...

# rtorrent log file
create_files_pattern(rtorrent_t, rtorrent_log_t, rtorrent_log_t)
...

Thats too obvious ...

> Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090717/5cc79b82/attachment.bin 

  reply	other threads:[~2009-07-17  9:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09  9:58 [refpolicy] new policy: rtorrent Max Kellermann
2009-07-09 12:21 ` Dominick Grift
2009-07-09 12:31   ` Dominick Grift
2009-07-17  9:09   ` Max Kellermann
2009-07-17  9:58     ` Dominick Grift [this message]
2009-07-14 13:22 ` Christopher J. PeBenito
2009-07-17  9:13   ` Max Kellermann
2009-07-17 10:21     ` Dominick Grift

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=1247824730.19628.12.camel@notebook2.grift.internal \
    --to=domg472@gmail.com \
    --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.