Bug 421951
Summary: | Selinux is preventing kdm to login a user | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sebastian Vahl <fedora> | ||||
Component: | kdebase-workspace | Assignee: | Than Ngo <than> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | high | ||||||
Version: | rawhide | CC: | dwalsh, fedora, kevin, ltinkl, rdieter | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-03-30 05:56:41 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 421891 | ||||||
Attachments: |
|
Description
Sebastian Vahl
2007-12-12 16:56:02 UTC
Created attachment 285901 [details]
audit.log after a login
I've removed the audit.log and restarted /etc/init.d/audit so that this log
file only contains the relevant messages.
How do I change to use the kdm_greeter? 1 install kdebase-workspace 2 edit /etc/sysconfig/desktop to contain: DISPLAYMANAGER="KDE" reboot/restart X restorecon -R -v /root To fix labeling on /root I am able to login but I also get the avc messages about writing to usr_t and locale_t. This looks like a bug in kdm_greet which is opening these files for write. It should only open them for read. KdmGreeterTheme.desktop entry.desktop and other desktop files. KDM, like many other things in KDE, uses KConfig to open .desktop files. KConfig decides automatically whether to open files read-only or read-write, using this logic: KConfigBase::AccessMode KConfigIniBackend::accessMode() const { if (filePath().isEmpty()) return KConfigBase::NoAccess; if (KStandardDirs::checkAccess(filePath(), W_OK)) return KConfigBase::ReadWrite; return KConfigBase::ReadOnly; } SELinux breaks this. This is KStandardDirs::checkAccess: bool KStandardDirs::checkAccess(const QString& pathname, int mode) { int accessOK = access( QFile::encodeName(pathname), mode ); if ( accessOK == 0 ) return true; // OK, I can really access the file // else // if we want to write the file would be created. Check, if the // user may write to the directory to create the file. if ( (mode & W_OK) == 0 ) return false; // Check for write access is not part of mode => bail out if (!access( QFile::encodeName(pathname), F_OK)) // if it already exists return false; //strip the filename (everything until '/' from the end QString dirName(pathname); int pos = dirName.lastIndexOf('/'); if ( pos == -1 ) return false; // No path in argument. This is evil, we won't allow this else if ( pos == 0 ) // don't turn e.g. /root into an empty string pos = 1; dirName.truncate(pos); // strip everything starting from the last '/' accessOK = access( QFile::encodeName(dirName), W_OK ); // -?- Can I write to the accessed diretory if ( accessOK == 0 ) return true; // Yes else return false; // No } Any way to make this more SELinux-friendly? The question is what is doing this call? Is this something execd from the login program or run directly from the login program? It is making the assumption that the login program can access a users homedir? If this code was being executed in the users context and as the UID it should work. We are not currently allowing the login programs (xdm_t) to access home directories, because the login programs are starting to execute lots of programs without actually logging in. Things like setting up the network, Assistive Technologies etc. So we would like to prevent this. (Afaik) KConfig/KStandardDirs are in kdelibs, which can potentially be called by pretty much any other kde app or library. But this assumption might be wrong, and why should the login program care if it can access the homedirs. In the case of NFSV4 or afs the login program running as a different user will not be allowed to access the homedir. Well, that code tests if it can write to the config file and if not opens it read only. It's true that the case where there's no read access either is not handled in this function, but that's caught elsewhere. The problem as I understand it (but I'm no SELinux expert) is that with SELinux, the permissions are such that access should succeed, but SELinux blocks the access and logs an avc warning. Rejecting the access is harmless because the config file will just be opened read only and that's all KDM really needs, the problem is the spurious avc. So what I'm asking is how to fix this code so it still does what it's supposed to (checking whether the file can be opened for writing or not) without triggering SELinux avc log entries. Yes I can do that, but my only means to do it is to ignore all write attempts to the homedir. So if the program was somehow subverted or someone was attempting to subvirt it no error messages would be sent. I will add the dontaudit in next update. Fixed in selinux-policy-3.3.1-26.fc9 Thanks, but what I was really asking is whether we can fix the code in KDE so you don't have to add that dontaudit. Also because this may in principle affect other KDE apps (this code is common kdelibs code, though most other KDE apps will not try accessing config files in users' home directories) and your dontaudit only fixes it for KDM (but again, KDM is the only known case of this actually happening, so maybe that's sufficient after all). |