From: martin@martinorr.name (Martin Orr)
Date: Tue, 28 Jul 2009 11:12:02 +0100
Subject: [refpolicy] Critique requested
In-Reply-To: <20090727161322.GA4823@deer-run.com>
References: <20090718230224.GB26512@deer-run.com>	<1247996268.2564.38.camel@notebook1.grift.internal>
	<20090727161322.GA4823@deer-run.com>
Message-ID: <4A6ECEF2.7080707@martinorr.name>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 27/07/09 17:13, Hal Pomeranz wrote:
> Thanks to Dominick for critiquing my initial attempts at using 
> the Reference Policy.  I'm still curious about the answer to the
> following question, if anybody on the list has some insights:
> 
>>> Also a question, if I may.  I originally compiled portsentry from
>>> source as a standard dynamically-linked executable.  However, when I
>>> started this binary under SELinux control I kept getting denials on
>>> the shared library "lib_t" files and directories as well as on various
>>> "ld_so*_t" files.  Recompiling as a statically-linked executable made
>>> this problem go away (obviously), but what's the magic to get a
>>> standard dynamically-linked executable to not generate these errors?
>>> I've looked at the sample files in the refpolicy source and haven't
>>> been able to figure out the trick.


This permission is given by:
	libs_use_ld_so(domain)
	libs_use_shared_libs(domain)
in kernel/domain.te.

Any type declared with domain_type will get these permissions.

If you still see denials for these after using domain_type, then maybe you
are using an old policy: this was added to the policy in October 2008.

-- 
Martin Orr