Description of problem: Upstart still suffers from a few kde-related AVCs Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Log in 2. 3. Actual results: Four AVCs produced Expected results: No AVCs. Additional info: host=david.lydgate.lan type=AVC msg=audit(1208438083.551:5): avc: denied { write } for pid=2505 comm="kdm_greet" name="ObsidianCoast.colors" dev=dm-2 ino=29257 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file host=david.lydgate.lan type=SYSCALL msg=audit(1208438083.551:5): arch=40000003 syscall=33 success=yes exit=0 a0=9900d90 a1=2 a2=57ea290 a3=9900d80 items=0 ppid=2501 pid=2505 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) *** host=david.lydgate.lan type=AVC msg=audit(1208438084.65:6): avc: denied { write } for pid=2505 comm="kdm_greet" name="entry.desktop" dev=dm-2 ino=28548 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:locale_t:s0 tclass=file host=david.lydgate.lan type=SYSCALL msg=audit(1208438084.65:6): arch=40000003 syscall=33 success=yes exit=0 a0=9986818 a1=2 a2=57ea290 a3=9986808 items=0 ppid=2501 pid=2505 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) *** host=david.lydgate.lan type=AVC msg=audit(1208438111.670:10): avc: denied { read } for pid=2527 comm="lnusertemp" name="tmp-david.lydgate.lan" dev=dm-2 ino=139644 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=lnk_file host=david.lydgate.lan type=SYSCALL msg=audit(1208438111.670:10): arch=40000003 syscall=85 success=yes exit=13 a0=bfe77b07 a1=bfe75b05 a2=1000 a3=bfe75b05 items=0 ppid=2505 pid=2527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lnusertemp" exe="/usr/libexec/kde4/lnusertemp" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) *** host=david.lydgate.lan type=AVC msg=audit(1208438111.661:9): avc: denied { getattr } for pid=2527 comm="lnusertemp" path="/root/.kde/tmp-david.lydgate.lan" dev=dm-2 ino=139644 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=lnk_file host=david.lydgate.lan type=SYSCALL msg=audit(1208438111.661:9): arch=40000003 syscall=196 success=yes exit=0 a0=bfe77b07 a1=bfe75aa4 a2=582ff4 a3=1000 items=0 ppid=2505 pid=2527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lnusertemp" exe="/usr/libexec/kde4/lnusertemp" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) NB - none of these caused a pop-up alert
These AVC's indicate that kdm_greet is trying to write to two files in the /usr directory? /usr/share/kde4/apps/color-schemes/ObsidianCoast.colors /usr/share/locale/l10n/*/entry.desktop I don't believe needs to do this and would be blocked by a read only /usr partition, I do not want to dontaudit this, since this would block me from seeing a real attack. It is also trying to stat the /root/.kde/tmp-david.lydgate.lan lnk_file, which is I guess a link created in the homedir of kde applications? Not sure what it is trying to do. But I think kdm_greet should at least fix the writing of the two files above.
.colors and .desktop files are all read using KConfig, so this is almost certainly the same issue you already added a dontaudit for in the home directory case: KConfig will always try to open a config file for writing first, and if permission is denied, retry as read-only.
My idea would be to link KStandardDirs with libselinux and use something like this (which probably has bugs and which doesn't check the return values of getcon, getfilecon and security_compute_av, don't use as is): bool KStandardDirs::checkAccess(const QString& pathname, int mode) { // if we want to write to the file, first query SELinux to avoid AVCs if ((mode & W_OK) && is_selinux_enabled()) { security_context_t scon, tcon; struct av_decision decision; getcon(&scon); getfilecon(QFile::encodeName(pathname), &tcon); security_compute_av(scon, tcon, SECCLASS_FILE, FILE__WRITE, &decision); freecon(scon); freecon(tcon); if (!(decision.allowed & FILE__WRITE)) return false; } // the code below is original KDE code 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 } Would this work?
(If this works, it would also make the dontaudit you added for bug 421951 unnecessary.)
Well the problem with this is you are giving a lot more access to be able to check versus just dontaudit the effort to write the file. I guess we can just dontaudit the access.
Of course if kdm_greet did not run as root, like gdm does, DAC permissions would prevent these checks. dontaudits added in selinux-policy-3.3.1-37.fc9.src.rpm