From: domg472@gmail.com (Dominick Grift)
Date: Thu, 04 Aug 2011 11:34:13 +0200
Subject: [refpolicy] [PATCH/RFC] Add support for the skype_t domain
In-Reply-To: <201108041900.39165.russell@coker.com.au>
References: <20110724153808.GA25350@siphos.be>
	<201108040904.50416.russell@coker.com.au>
	<1312447306.2134.27.camel@localhost.localdomain>
	<201108041900.39165.russell@coker.com.au>
Message-ID: <1312450465.2050.21.camel@localhost.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Thu, 2011-08-04 at 19:00 +1000, Russell Coker wrote:

> But these aren't the only such files.  I'm sure that there are other files 
> that may be executable by common programs that run as user_t.  Making a 
> comprehensive list will be difficult.  Also there are lots of local config 
> files that don't get fuzz testing because writing to them requires equivalent 
> privs to messing with the application directly.
> 

In a pretty much perfect confined user environment those are the only
files that come to mind here atleast.

The implementation would rely heavily on name file transition
functionality and/or the presence of restorecond -u running in the
session.

> The assumption all along was that user_home_t was in most ways the most 
> privileged of all types for files under the user home directory (with the 
> possible exception of gpg_secret_t).  Changing this assumption isn't going to 
> be easy.
> 

Agreed there. For this to work, basically everything in the user
environment needs to be confined. Starting with the layer between the
user and the system (the desktop environment)

Unfortunately it is not going to happen. At least not any time soon.

I can understand that for this reason (currently too much work, too
difficult to maintain) but i do not understand that reference policy
accepts a workaround like the one that is proposed for skype.

Tool little benefit and an endorsement that we should accept workarounds
like these. what if i propose a similar patch for lets say Ekiga (what
about empathy (insert the next gui app here)), are we going to implement
a boolean for its file sharing functionality to? where is it going to
end?

Might as well ignore the GUI environment altogether until we find a
solution that actually deals with integrity issues in a more credible
way.

end of rant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110804/7da143d2/attachment.bin