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