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.
--
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.
