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
|
