From mboxrd@z Thu Jan  1 00:00:00 1970
From: guido@trentalancia.com (Guido Trentalancia)
Date: Wed, 27 Jun 2012 20:28:00 +0200
Subject: [refpolicy] [PATCH v2]: fix packagekit file context (standard
 location for the daemon)
In-Reply-To: <1340817239.27654.5.camel@x220.mydomain.internal>
References: <1340207771.3570.11.camel@vortex>
	<1340240971.2940.2.camel@vortex> <4FE9BCD9.7010307@tresys.com>
	<1340718653.12652.1.camel@x220.mydomain.internal>
	<4FE9C1CB.4060804@tresys.com> <1340739584.2840.2.camel@vortex>
	<1340739947.12652.7.camel@x220.mydomain.internal>
	<1340816399.3001.8.camel@vortex>
	<1340817239.27654.5.camel@x220.mydomain.internal>
Message-ID: <1340821680.2819.20.camel@vortex>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello again Dominick.

On Wed, 2012-06-27 at 19:13 +0200, Dominick Grift wrote:
> On Wed, 2012-06-27 at 18:59 +0200, Guido Trentalancia wrote:
> >  an hijacked copy of
> > policykitd installed in the other location would be able to run with the
> > same permissions as the trusted packagekitd without the user noticing
> > anything.
> 
> It would not have to be installed in the other location for it to be
> able to do damage. Same thing could also happen with a single location.

Yes, although it's a little bit more difficult to detect. That's why, I
was suggesting to introduce an optional last field for enforceable
hash-based digest verification (at that point only heuristic run-time
analysis would be missing).

> This is why it is important to only install packages from trusted
> sources. SELinux is no substitute for that imho.

Yes, it's an unsigned package therefore an hijacked version could be
easily be injected while in transit on the network(s) as a substitute
for the authentic version by a man in the middle.

The last thing I can add is that 0.6.x is apparently considered as
stable (it should follow the even/stable odd/unstable rule), therefore
you now have all the information to make an (informed) choice about it.

> Think about it, a distro like Fedora has modules for all kinds of
> services and applications of which many you may not even have installed:

I am not using Fedora.

> example:
> 
> # semanage fcontext -l | grep unconfined_exec_t
> /usr/bin/vncserver                                 regular file
> system_u:object_r:unconfined_exec_t:s0 
> /usr/sbin/xrdp                                     regular file
> system_u:object_r:unconfined_exec_t:s0 
> /usr/sbin/xrdp-sesman                              regular file
> system_u:object_r:unconfined_exec_t:s0 

It should possible to turn off individual modules as long as there is
enough granularity in modules. But, to be honest, I have not tested
whether or not that always behaves as expected.

Regards,

Guido