Re: sandboxing rpms
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