From: russell@coker.com.au (Russell Coker) Date: Thu, 4 Aug 2011 19:00:38 +1000 Subject: [refpolicy] [PATCH/RFC] Add support for the skype_t domain In-Reply-To: <1312447306.2134.27.camel@localhost.localdomain> References: <20110724153808.GA25350@siphos.be> <201108040904.50416.russell@coker.com.au> <1312447306.2134.27.camel@localhost.localdomain> Message-ID: <201108041900.39165.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, 4 Aug 2011, Dominick Grift wrote: > On Thu, 2011-08-04 at 09:04 +1000, Russell Coker wrote: > > Now if you are proposing separate types for .bash* files etc then it > > might be more reliable. > > I guess .bash.* (and others) are configuration files etc of the (bash) > shell which i guess in a way is a user agent. As the shell is started by the system on behalf of the user before anything else happens it is the ultimate user agent. Note that there are more than a few shells available which use different configuration files. > The only difference is > that the shell does, and is supposed to run in the user domain and that > these files are copied from /etc/skel. Fortunately the named file > transition functionality can help overcome this issue. Yes, named file transition is necessary if we want to solve that by using a different type for the shell config files. 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. 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. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/