On Sat, Dec 27, 2008 at 06:43:58AM -0500, Daniel J Walsh wrote: > Michal Jaegermann wrote: > > > > So far, AFAICT, when installing a machine "from scratch", and while > > keeping a layout as plain as possible, then selinux is rather > > expected to work; at least decently enough. The picture becomes > > entirely diferent when you are trying to upgrade a distro. What > > results of such exercise will be I am unable to predict. ... > > This works but I am getting every > > time "Unable to get valid context for root" and in /var/log/secure: > > "pam_selinux(sshd:session): Security context > > system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for > > system_u:system_r:logrotate_t:s0-s0:c0.c1023". > > Eh? What this is supposed to mean? > /root is supposed to be labelled admin_home_t and most confined > applications are not allowed to read/write anything in this directory. > So procmail_t should not be allowed by default to read/write > admin_home_t. As a matter of fact it was not and it is still not doing that. Here procmail is used to reclassify and to send further mail, using less blunt means that an alias in /etc/aliases (and ensuring that any "outside" mail to root would land in /dev/null), and in this particular case it happens that none of these mails ends up in subdirectories of /root/. If and where procmail writes its temporary files, which apparently triggered some complaints, I really cannot tell without diving into sources. Besides even if root procmail would be storing some mails locally then who says that it would have to do that below /root/? Only this is not here nor there. I can work around this particular issue, although this would add extra complications and in more involved cases such hacks would be highly undesirable, but this was not the real question. This was just a specific example of what was triggered by an upgrade. > If for some reason you want procmail to deliver files to > root, you can add a custom module, as you seem to have indicated that > you have. Yes, I did and the only effect was a slight change in complaints with 'allow2why' now playing dumb so now what I can do? That still does not explain why I am seeing, for example, "system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for system_u:system_r:logrotate_t:s0-s0:c0.c1023" with logwatch later producing mulitiple "NULL security context for user, but SELinux in permissive mode, continuing ()" and none of tools which I have giving me any clues why. It is possible that I do not know where to look but I only see in audit.log entries with "res=failed" immediately followed by "res=success" in the next line. What other catastrophies are still lurking there it remains to be seen. The real question was why I am running an upgrade on one machine and I am ending up with a disaster and apparently the same action elsewhere has entirely different effects and if there is anything I can do about it. Only now you are implying that what works is really broken. That is nice to know. > Why /root on the other machine is labeled user_home_t is a > bug. Not sure why this is happening. Do you have an entry in your > /etc/passwd with a UID > 500 with /root as a home dir? Of course not. The only entries in /etc/passwd with /root for a home directory look as follows: root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin > I have changed > the tools that setup homedir labeling to not modify /root but I am not > sure if this has gotten into F10 yet. I only know that running 'restorecon -Rv /root' on either of these two "example" machine does not change anything even if labelling is different. OTOH in none of these cases an initial labelling was created "by hand". > The reason we want to protect /root from confined domains, is to stop > them from modifying /root/.bashrc or other files that the admin could be > tricked into executing. The old principle says "if you will disallow dumb things then you will block smart things as well" and necessity of complicated workarounds open its own security holes - possibly more disastrous than what you were trying to guard against in the first place. Michal -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
