From: domg472@gmail.com (Dominick Grift)
Date: Fri, 17 Jul 2009 11:58:50 +0200
Subject: [refpolicy] new policy: rtorrent
In-Reply-To: <20090717090925.GA1884@squirrel.roonstrasse.net>
References: <20090709095817.GA7703@squirrel.roonstrasse.net>
	<1247142105.5300.12.camel@notebook2.grift.internal>
	<20090717090925.GA1884@squirrel.roonstrasse.net>
Message-ID: <1247824730.19628.12.camel@notebook2.grift.internal>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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