Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Brindle wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Policy should label /root with one label and this should not be
effected
by the passwd database.
In Fedora policy we label this as admin_home_t. Having this
label
vary
depending on policy ends up with lines like
dontaudit * user_home_t:dir search_dir_perms
dontaudit * admin_home_t:dir search_dir_perms
dontaudit * sysadmin_home_t:dir search_dir_perms
dontaudit * staff_home_t:dir search_dir_perms
Labeling this directory as user_home_t, opens the system to
possible
security risks since some domains have to be able to write to
user_home_t when they would never be allowed to write to
admin_home_t.
The comment right above the added lines seems to indicate
that was
suppose to be root before, why is / excluded? Are we going to
start a
huge whitelist for genhomedircon?
if (strcmp(pwent->pw_dir, "/") == 0) {
/* don't relabel / genhomdircon checked
to see
if root
* was the user and if so, set his home
directory to
* /root */
continue;
}
No just /root
/root should not be labeled based on genhomedircon.
Why are the exact same lines there for "/" then?
Well I guess we do want to protect / and /root.
Others should be fixed by looking at the parent, so if I added /var
as a
homedir it would blow up saying it conflicts with the previous
definition of /var.
I don't think I understand the problem we are trying to solve
here...
Right now we do not know what /root is going to be labeled.
Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
times user_home_dir_t.
I believe this is wrong. It is not a "USER" home dir, it is
something
far more special.
Allowing it to be set by an application like genhomedircon,
prevents us
from knowing what the label should be.
Chris and I talked about this and we both think the same thing,
genhomedircon is not in the business of knowing who is and is not an
administrative user, "special" user, etc. root _is_ a user, and on an
SELinux system can be an unprivileged user.
I think hardcoding in the library the specialness of /root is a bad
idea, what if someone changes roots default role to user_r to make it
unprivileged? They'd also need to change the file context entries
explicitly with this patch rather than genhomedircon simply
updating the
entries.
The problem with treating /root as the same as every other homedir, is
confined daemons all consider /root their home dir, so they want to be
able to read/write contents in the homedir. Lots of domains look at
the
homedir and or getstarted in the /root directory and end up causing an
AVC looking at the current working directory. So we end up with a
dontaudit_search_admin_home_dir. Which will not work if the context of
the homedir varies.
I don't see where the source of the problem is coming in here. Is it
because end users are changing the role of root and there are all of a
sudden denials? If end users are changing roots role they probably would
need to add some policy.
Allowing user_r on the /root directory would be a bad idea since he
would be able to modify .bash_profile and other scripts that could
effect the way that a real admin works.
There are legitimate use cases where root should be unprivileged
(embedded systems, appliances, etc). We allow that flexibility and can't
undermine it in a hard coded way in the library.
So I will carry the patch and eventually would like to get rid of
I really don't think you should do this. My objections to merging it are
rendered moot if the primary selinux distribution ships it anyway.
genhomedircon all together an move to a mechanism where an admin can
specify where his homedirs are and where is altermate directories are.
So why not add this feature now? A simple variable in semanage.conf
should suffice.
/home == /export/home
Which would then duplicate all of the contexts prefixed with /home to
/export/home
Similarly
/var/www == /src/www
This would give administrators greater flexibility and would get us out
of the business of guessing what a homedir, is.
Case in point.
https://bugzilla.redhat.com/show_bug.cgi?id=486147
I have no way of dontauditing this if I allow the /root directory to
have flexible labeling.
You will always know what the label of /root will be in the default
configuration. These sorts of denials are going to happen on
admin_home_t whether genhomedircon labels it that way or there are
explicit labels.
If, however, you modify genhomedircon you'll make the situation worse if
an end user does decide to change roots role, their login won't work,
there will be all sorts of denials (denials that look like possible
intrusions I might add) and the user is going to have to explicitly
relabel /root anyway (which will cause the kind of denials you are
talking about). By making it harder on users to change the root role you
aren't solving the problem, you are just making it harder on users that
have a legitimate need to change the role.
I repeat file context on disk should NOT be variable.
genhomedircon is about finding context for USER homedirectories. If you
want a random user type to be able to login as root, then set the
correct privileges for the user. Don't change the labeling.
That is the case _for you_ ! That doesn't mean that no one else needs this
capability, nor that we should remove it for all end users. We still work on
systems here where we use types for confining users from one another and need
those home directories labeled differently.
Just because one downstream wants to keep user home dirs all labeled the same
thing doesn't mean we remove that from the toolchain.
If you don't want genhomedircon behavior anymore remove all the USER and ROLE
file contexts from your policy, then you won't have anything added by genhomedircon.
We don't allow you to change the labeling on /var if you happen to
specify /var as a home dir, so don't change it for /root.
If I want to write a rule that says qemu_t can transition to
qemu_admin_pulse_t when creating files in /root/.pulse which is labeled
admin_pulse_t then don't change the context out from under me.
Similar context might be written for sshd_t and others to allow them
access to certain files in the /root dir, but you want this directory to
suddenly change labels. I could not disagree more.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
