sandboxing rpms

[Stephen Smalley]

On Thu, 2005-12-08 at 16:15 -0600, Benjamin Youngdahl wrote:
> Greetings.  
> 
> My understanding is that RPM packages will be able to install policy
> modules in FC5, an improvement over a monolithic policy.  I have a
> couple of questions about the implementation:
> 
> 1.  Is it possible to provide a temporary policy (either external, or
> with an RPM) that constains what the specific RPM's installation can
> do?
>
> The motivation here is that when I install an RPM, it would be nice if
> I would be able to get a declarative list of what the RPM wants access
> to do.  The RPM tool might summarize before installing the package
> what the package will be allowed to do, by parsing this "installation
> sandbox" policy. 

Not yet.

> 2.  Is it possible to limit (or discover easily in advance) what
> changes to the system policy are being made by the RPM's policy
> modules?
> 
> The motivation being that I want to be sure that the policy modules
> installed by an RPM are well behaved concerning overall system
> constraints. 
> 
> Apologies in advance if these questions are way off-base, or belong
> somewhere else.

When a module is installed, the base policy assertions (defined by
neverallow statements in the base policy) are re-checked and the module
is rejected if it invalidates one of those assertions.  Further,
libsemanage can be configured to execute verification programs at
certain steps in the process of installing a new module to check
properties on the resulting policy.  Such verification programs remain
to be written.  The policy language also now supports a notion of
hierarchical roles and types, where type a.b is strictly limited to a
subset of the permissions granted to type a, to allow portions of the
policy to be reasonably delegated.  Ongoing work on a policy management
server will provide a way to perform fine-grained access control over
policy, but that won't be in FC5.

-- 
Stephen Smalley
National Security Agency