Bug 421951 - Selinux is preventing kdm to login a user
Selinux is preventing kdm to login a user
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
rawhide
All Linux
high Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks: KDE4Live
  Show dependency treegraph
 
Reported: 2007-12-12 11:56 EST by Sebastian Vahl
Modified: 2008-03-30 02:02 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-30 01:56:41 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)
audit.log after a login (32.22 KB, text/plain)
2007-12-12 11:57 EST, Sebastian Vahl
no flags Details

  None (edit)
Description Sebastian Vahl 2007-12-12 11:56:02 EST
Description of problem:
With selinux in enforcing mode kdm is unable to login a user.


Version-Release number of selected component (if applicable):
kdebase-workspace-3.97.0-2.fc9

How reproducible:
ever


Steps to Reproduce:
1. set selinux in enforcing mode (setenforce 1)
2. try to login in kdm
3. watch /var/log/audit.log
 
Actual results:
login would be stopped and kdm re-appears.

Expected results:
User is able to login

Additional information:
If you set selinux to permissive mode login would be possible.
Also setroubleshoot doesn't have an entry nor /var/log/messages (this was 
tested on a livecd)
Comment 1 Sebastian Vahl 2007-12-12 11:57:44 EST
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.
Comment 2 Daniel Walsh 2008-01-07 13:01:13 EST
How do I change to use the kdm_greeter?
Comment 3 Rex Dieter 2008-01-07 13:07:08 EST
1 install kdebase-workspace 
2 edit  /etc/sysconfig/desktop to contain:
DISPLAYMANAGER="KDE"

reboot/restart X
Comment 4 Daniel Walsh 2008-01-08 12:00:40 EST
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.
Comment 5 Kevin Kofler 2008-03-10 17:32:03 EDT
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.
Comment 6 Kevin Kofler 2008-03-10 17:49:46 EDT
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?
Comment 7 Daniel Walsh 2008-03-11 17:44:48 EDT
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.
Comment 8 Rex Dieter 2008-03-29 12:31:15 EDT
(Afaik) KConfig/KStandardDirs are in kdelibs, which can potentially be called
by pretty much any other kde app or library.
Comment 9 Daniel Walsh 2008-03-29 12:38:05 EDT
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.
Comment 10 Kevin Kofler 2008-03-29 19:23:50 EDT
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.
Comment 11 Daniel Walsh 2008-03-30 01:56:41 EDT
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
Comment 12 Kevin Kofler 2008-03-30 02:02:17 EDT
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).

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