From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 04 Aug 2011 10:22:07 -0400
Subject: [refpolicy] [PATCH/RFC] Add support for the skype_t domain
In-Reply-To: <1312450465.2050.21.camel@localhost.localdomain>
References: <20110724153808.GA25350@siphos.be>
	<201108040904.50416.russell@coker.com.au>
	<1312447306.2134.27.camel@localhost.localdomain>
	<201108041900.39165.russell@coker.com.au>
	<1312450465.2050.21.camel@localhost.localdomain>
Message-ID: <4E3AAB0F.70405@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/04/2011 05:34 AM, Dominick Grift wrote:
> 
> 
> 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.
> 
> 
> 
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy


Best solution would be to have a helper File Selector app that does the
opening of files from the file manager and then passes the open file
descriptor to the application.  That way you could prevent the random
opening of files in the homedir, while allowing apps to read/write any
passed in file descriptors.

But alas this is not the way it works...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk46qw4ACgkQrlYvE4MpobPVZACgqiwfrOMQMj0nv4rEzc9Xafrh
Oj8AoJreyxS3uu73wchry90kgDX2G0Cv
=B8M1
-----END PGP SIGNATURE-----