Bug 163668 - RFE for local adaptation
RFE for local adaptation
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-19 23:53 EDT by Jonathan S. Shapiro
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-19 16:17:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2005-07-19 23:53:45 EDT
This is really an RFE. There is probably a way to do it already that I do not
understand. I would welcome a pointer to documentation on how to effectively
administer selinux if you know of any. The supplied docs are, ahem, opaque.

Context: I run a server with several logical web severs. Each has its own file
tree. Also, I have two directories that need to be treated like /home: /home and
/guest.

Problem: restorecon -R / screws up the file contexts on these non-conventional
directories.

Exacerbation 1: if I edit the file_contexts file, then updates of the selinux
policy fail.

Exacerbation 2: when that helpful dwalsh guy decides to update the contexts on
the "standard" locations, they don't propagate to my directories.

What I *think* I want is in three parts:

1. a way to say: "treat this directory /mumble and its sub-content in all
respects as though it were that other directory /home". I'm not stuck on "define
by example," but I at least want a way to know when my adapted config has gone
stale.

2. a way to add file contexts without editing the master file_contexts file.
Perhaps this might be done in a way similar to the handling of /etc/yum.repos.d/
or /etc/httpd/conf.d/, wherein all files present get loaded in unspecified order.

3. On the "your adapted config has gone stale", I *really* want to know this
*before* I reboot. On some occasions, selinux upgrade failures (primarily due to
the .rpmnew problem that I filed separately) have left me with machines that
don't reboot past single user mode. This leaves me doing an hour drive in and
out of work in the middle of the night to "recover" the file system with
restorecon and then patch it for my unusual directories. This prompts me to
suggest that I want more direct control on policy upgrades in the same kind of
way that I have on kernel upgrades -- for that matter, I wouldn't mind more
control over the kernel upgrades. It's bad enough that I'm about ready to put
selinux on my "do not upgrade automatically" list.

Not quite sure how to get the control. One possibility is to leave the existing
policy in place so that I can roll back. Another might be to leave the decision
to migrate forward as a manual decision.

I'm afraid I don't know enough to supply a useful patch here. I'm mostly
articulating these issues in the hope that some simple solution to some of it
may occur to someone who knows more than I do.
Comment 1 Daniel Walsh 2005-07-20 09:20:18 EDT
Two things.  First you can put custom file context in 

/etc/selinux/targeted/contexts/files/file_context.local

Which will survice a policy update.

Also genhomedircon should be picking up the fact that you have users in the
/guest directory and label it correctly.  Do you have users in your passwd files
with /guest as the root of the home dir?

You should see definition in file_contexts.homedirs?

Theoretically Issue 1 and 2 should be handled by this.  Issue three should not
happen.  Do you have a mismatch between the default kernel and the policy?

Dan
Comment 2 Jonathan S. Shapiro 2005-07-20 10:22:51 EDT
Now that I think about it, genhomedircon probably *is* working for the home
directories. I'm unclear when genhomedircon runs, however, and that would be
useful to know.

I'll try file_context.local for case 2 and see how that goes.

Issue three definitely *does* happen. Now that you raise the kernel versioning
issue, it occurs to me that in many of the cases where I have observed this
problem, the selinux policy and the kernel have been upgraded simultaneously by
yum and the selinux policy postinstall then failed as described in the other bug
that I filed. Not sure if that is related or not.
Comment 3 Daniel Walsh 2005-07-25 13:51:22 EDT
Genhomedircon is run when you upgrade the policy.

Also if you are customizing policy-sources it is also run
Comment 4 Daniel Walsh 2005-09-19 14:17:52 EDT
Any update on this bug?
Comment 5 Jonathan S. Shapiro 2005-09-19 15:10:58 EDT
I've made some definite progress using file_context.local; that was very
helpful. There remains the issue of "treat this directory like that one" for Xen
installs, but I propose that we should handle that with a separate bug report.

Given which, I'm content to close this bug.

Note You need to log in before you can comment on or make changes to this bug.