From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 02 Mar 2009 10:57:20 -0500
Subject: [refpolicy] [PATCH] add policy for Icecream
In-Reply-To: <20090302163716.68641b3a@leela>
References: <20090302130427.0befcb52@leela>
	<1235999814.19155.19.camel@notebook1.grift.internal>
	<20090302163716.68641b3a@leela>
Message-ID: <1236009440.7000.20.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2009-03-02 at 16:37 +0100, Michal Schmidt wrote:
> Dne Mon, 02 Mar 2009 14:16:54 +0100
> Dominick Grift <domg472@gmail.com> napsal:
> 
> > Here is my take on the policy. It may or may not work but it may give
> > you some ideas on how to clean it up a bit.
> 
> Thank you for your suggestions! I'll redo the policy accordingly.
> There are some bits, however, where I'd like some clarification.
> It's these pieces of the diff between my and your version of
> the .te file:
[...]
> >  type iceccd_createenv_t;
> >  type iceccd_createenv_exec_t;
> > -domain_type(iceccd_createenv_t)
> > -domain_entry_file(iceccd_createenv_t, iceccd_createenv_exec_t)
> > +application_executable_file(iceccd_createenv_exec_t)
> > +application_domain(iceccd_createenv_t, iceccd_createenv_exec_t)
> >  role system_r types iceccd_createenv_t;
> 
> The application_* interfaces mark programs which are expected to be run by
> users from interactive shells?

Yes.

>  OK, it makes sense for icecc-create-env.
> 
> > -domain_type(iceccd_untrusted_t);
> > -domain_entry_file(iceccd_untrusted_t, iceccd_cache_t)
> > +application_executable_file(iceccd_cache_t);
> > +application_domain(iceccd_untrusted_t, iceccd_cache_t)
> 
> ... however, I do not think it's useful to mark the untrusted foreign compilers
> as such. These should never be run by users.

I agree in this case.

> > +dontaudit iceccd_t iceccd_untrusted_t:process { siginh rlimitinh
> > +noatsecure };
> 
> In the original version, these three permissions were 'allow'. I don't know
> exactly what they mean, I got them by observing the AVC denials during normal
> operation of Icecream. If you think 'dontaudit' should be enough, I believe
> you. I'll test it.

With dontaudit, the transition to icecd_untrusted_t, signals and
resource limits won't be inherited, and the environment variables will
be cleansed.  Its rare that these permissions need to be allowed.

> > +# use interface: iceccd_untrusted_signal()
> > +allow iceccd_t iceccd_untrusted_t:process signal;
> 
> You suggest "use interface: ..." several times. To make it absolutely clear -
> are you asking me to create the named interfaces in icecream.if and use them in
> icecream.te?
> I thought interfaces were only useful for interaction with other policy
> modules. And at the moment I can't imagine any other users of these interfaces.

I'd lean towards skipping the interface for now.

> >  corenet_all_recvfrom_unlabeled(iceccd_t)
> >  corenet_all_recvfrom_netlabel(iceccd_t)
> >  corenet_tcp_sendrecv_generic_if(iceccd_t)
> > -corenet_udp_sendrecv_generic_if(iceccd_t)
> >  corenet_tcp_sendrecv_generic_node(iceccd_t)
> > -corenet_udp_sendrecv_generic_node(iceccd_t)
> >  corenet_tcp_sendrecv_all_ports(iceccd_t)
> > -corenet_udp_sendrecv_all_ports(iceccd_t)
> >  corenet_tcp_bind_generic_node(iceccd_t)
> >  corenet_tcp_bind_iceccd_port(iceccd_t)
> 
> iceccd sends UDP broadcasts to find the scheduler on the LAN. Won't removing
> these rules block it?

Yes.  Sounds like you need to keep those lines.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150