Finally getting back to this after vacations and all, apologies for the
lenghty delay...
On Tue, 7 Jul 2009, Joshua Brindle wrote:
Panu Matilainen wrote:
Hi,
On Mon, 6 Jul 2009, Stephen Lawrence wrote:
<snip>
Obviously I'm glossing over many implementation details that would need
to be worked out. The point of this email is strictly to get feedback on
our approach. Below is a patch that implements the beginnings of what I
describe above. Any and all feedback is appreciated.
Loading the policies at pre-trans stage is how it needs to be done, but
calling out to semodule is a no-go. It'd work for upgrades more or less,
but on initial installation (to an empty chroot) the pre-trans stage
happens in a complete void, there's just nothing there, not even /bin/sh.
It needs to be done through API calls, no way around it. On the surface
it doesn't look that bad, skipping over details like error handling,
rpmtsLoadPolicy() might be something like:
We wanted to fork/exec semodule because there would be a domain transition
and we could give semodule permission to update the policy without giving rpm
that permission. This feeds in to our ultimate desire to break RPM in to less
privileged pieces.
FWIW the library executes apps as well, for example setfiles is run to
validate the file contexts files when new policy is loaded. This is how we
break out functionality in SELinux to let pieces be less privileged. I don't
think we can attain our end goals if fork/exec is never allowed.
It's not so much a matter of allowing or not, but what's possible.
Chroot'ed operation (initial install and otherwise) is not an oddball
corner case but one of the most important use-cases for rpm, and needs to
be taken into account as such everywhere.
But ok... looking that little bit closer: unlike %pretrans scriptlets, the
policy load happens *outside* any chroot using the hosts
/usr/sbin/semodule always. This changes the landscape considerably and
mostly eliminates my "early bootstrap" concerns, sorry for missing that
previously.
Some odds and ends that come to mind:
- What to do in various failure cases, such as to-be-installed packages
containing loadable policies but /usr/sbin/semodule doesn't exist on the
host and --nopolicy was not specified? Aborting the transaction in
while already in rpmtsRun() seems rather unfriendly when the situation
is detectable earlier. Dynamic rpmlib() dependency might be one option.
- The /usr/sbin/semodule path should be macroized (a no-brainer)
- Is there some particular reason why installPolicy() is in the PSM?
It seems like an unnecessary complication to me, as AFAICT the operation
doesn't need any of the other PSM machinery (unlike %pretrans
which uses PSM to do chroot in+out + executing scriptlets from headers)
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
