From: max@duempel.org (Max Kellermann)
Date: Fri, 17 Jul 2009 11:09:25 +0200
Subject: [refpolicy] new policy: rtorrent
In-Reply-To: <1247142105.5300.12.camel@notebook2.grift.internal>
References: <20090709095817.GA7703@squirrel.roonstrasse.net>
	<1247142105.5300.12.camel@notebook2.grift.internal>
Message-ID: <20090717090925.GA1884@squirrel.roonstrasse.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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;

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?

> 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.

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

Max