On Thu, 27 Sep 2007, Karl MacMillan wrote:
On Thu, 2007-09-27 at 16:18 -0400, Jesse Keating wrote:
On Thu, 27 Sep 2007 15:53:38 -0400
Karl MacMillan <kmacmill@xxxxxxxxxx> wrote:
3) Have rpm set contexts that aren't yet valid. This option was
explored and there was even a kernel patch that would allow this. The
fear is that it would allow a malicious package to create files with
_any_ context that is not yet valid. It makes it difficult or
impossible to constrain rpm. You could go back after the policy is
installed and check for contexts that are still invalid and fix
those. No decision was reached about how to handle the hole and
nothing happened. The SELinux upstream developers (well, at least me)
are willing to reconsider this proposal.
Wouldn't it be reasonable to lay them down as 'undefined_t' and let the
post-rpm transactions relabel them?
That is possible - though obviously you have to handle things cleanly
for upgrades to that you don't end up with, say, libc labeled as
undefined_t. So you would have to:
1) check every context as you put a file down
2) if it is valid set it
3) otherwise, set to undefined_t (and ideally add file to list)
4) install policy in post
5) relabel (ideally with list kept from before)
Part of the problem, though, is figuring out what the context for a file
should be. I believe that you can record contexts from when the rpm was
built, but how do you handle if the admin has a local labeling rule that
should take effect?
Rpm has been recording file contexts into headers from build time up to
now, but nothing has been using it (except perhaps in early "selinux
bootstrap" days, I don't know). I just killed that code a couple of
weeks ago from rpm upstream, because it's just completely wrong: the
selinux policy that happens to be loaded on the build host has *zero*
relevance to that of the target host - could be local rules, or labeling
differences between targeted/strict/whatever prepackaged policies or
even just versions of the same policy.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
