Description of problem: /run/kdm protection mode permits any user to create a file that fills the /run tmpfs filesystem. This becomes a problem if additional services must create files in /run for tracking purposes. Version-Release number of selected component (if applicable): How reproducible: use the command "cp /dev/random xyz" to fill the filesystem Steps to Reproduce: 1. cd /var/run/kdm 2. cp /dev/random xyz 3. Actual results: cp: writing `./xyz': No space left on device cp: failed to extend `./xyz': No space left on device $ df . Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 4088848 4088848 0 100% /var/run $ ls -l --block-size=G total 4G -rw-rw-r--. 1 jesse jesse 4G Jun 9 10:09 xyz Expected results: permission denied/I/O error Additional info: Deleting the file releases the space. This is a local DOS problem. NO directory in /run (or /var/run) mounted tmpfs should have permissions rwxrwxrwt. when that filesystem is required for proper service functionality. /run should NOT allow users to create files there.
Ugh, why is /var/run/kdm world-writable? Does it have to be?
gdm does the same thing, fyi. The idea is to store X authority files here (locally) rather that in $HOME, to avoid issues with nfs/selinux, yada yada. See bug #524583
That may be, but gdm doesn't allow users to write to the directory. At least on my system gdm is listed as: $ ls -lZd gdm drwx--x--x. root gdm system_u:object_r:xdm_var_run_t:s0 gdm where kdm is: $ ls -lZd kdm drwxrwxrwt. root root system_u:object_r:xdm_var_run_t:s0 kdm Your statements would imply it should have the same access modes as gdm.
oh. One other thing. Even gdm doesn't prevent a user from sucking up the entire tmpfs space. The files created there for the xauthority and database are owned by the the user: # pwd /var/run # ls -RlZ gdm gdm: drwx--x--x. gdm gdm system_u:object_r:xdm_var_run_t:s0 auth-for-gdm-2iSxbK drwx--x--x. jesse jesse system_u:object_r:xdm_var_run_t:s0 auth-for-jesse-QDoquL gdm/auth-for-gdm-2iSxbK: -rw-------. gdm gdm system_u:object_r:xdm_var_run_t:s0 database gdm/auth-for-jesse-QDoquL: -rw-------. jesse jesse system_u:object_r:xdm_var_run_t:s0 database So even there it the user can overwrite the file and fill it. Now when the user logs out it may be deleted (not sure what happens then), but the directory "auth-for-jesse-QDoquL allows for any file to be created there. And that would still allow for DOS attack.
Lastly, There were reasons for the X authority file to reside in the users home directory: 1. users can add keys as necessary (requires write access) 2. users can delete keys as necessary (ditto) 3. users can remove the file if they want - sometimes useful, or at least it used to be. I used to delete the file occasionally and recreate it (using xauth) just to purge multiple keys at once. 4. the file was protected as much as the user wanted. Moving the file to /run just opens up a DOS attack path. Using SELinux labels on the file should be sufficient in the users home directory (or possibly as directed by the user login, selected/set via some other external configuration). I have run across one environment that did NOT want the xauthority in the home directory (they wanted it elsewhere) because the home directory was part of an AFS cell. The problem that added was that disk quotas could not be imposed very well, which opened the same DOS attack that exists with /run. Putting it in a subdirectory with different access controls permits the existing controls and prevents a DOS attack other than against the same user (in this case it is their fault).
My box has: ls -ld /var/run/gdm drwxrwxrwt. 3 root gdm 80 Jun 12 10:17 /var/run/gdm and gdm.spec includes: %attr(1777, root, gdm) %dir %{_localstatedir}/run/gdm which matches kdm packaging
Now, I suppose selinux policy could be updated to only allow certain processes to write here perhaps (unsure if that's the default already or not).
Thought of something... You might consider creating a small (4k?) tmpfs and mounting it as /run/auth-for-XXXX, and then using that. Might cause some issues with a multi-user system though, but much less than a DOS attack.
Re comment #7 (Rex Dieter): Relying on SELinux to block this security vulnerability is a bad idea, not everyone has SELinux enabled.
Even then. The DOS could just add keys to the authorization file until it fills the tmpfs.
(In reply to comment #6) > My box has: > > > ls -ld /var/run/gdm > drwxrwxrwt. 3 root gdm 80 Jun 12 10:17 /var/run/gdm > > and gdm.spec includes: > %attr(1777, root, gdm) %dir %{_localstatedir}/run/gdm > > which matches kdm packaging Interesting. Mine does not have this, yet rpm -qlv output on gdm shows that it should. However, it shows /var/run/gdm rather than /run/gdm (on F16 /var/run is a symlink to /run) -- perhaps something changed post-install? Anyways, both kdm and gdm should, I think be mode 0711, since these are privileged programs it should work (for gdm it obviously does as on F16 and 17, here, /run/gdm is mode 711 -- I can't speak for kdm but I suspect it would be the same). Someone could obviously change /run/kdm to 0711 and see if kdm still works properly... then we'd know for sure. I don't think having a bunch of user-specific tmpfs instances is the right way to go, nor do I think SELinux is necessary (beyond what is already in place). All these *dm applications should run privileged, so it should be enough to fix permissions on the directory.
As an aside, this is probably some legacy stuff where it didn't matter. Before, when /run was not tmpfs (not sure when this changed in Fedora, but looking at RHEL5 and 6), kdm had the same perms (1777) for /var/run/kdm. Normally this wouldn't be an issue since it's on /var, and /var can be written to by a user (i.e. /var/tmp), so they don't need to do anything fancy with kdm to abuse or fill up the filesystem. In Fedora now, with /run being on tmpfs it's slightly different. I don't know if the expectation is that /run should not/cannot/must not be written to by a regular user (if that expectation exists, please point me to the documentation). In light of that, I wouldn't call this a security flaw (unless the documented expectation exists). This is certainly a bug and a case for security hardening (I don't _think_ anything other than root or privileged daemons should write to /run, but that is more a personal opinion than anything else). Unless it breaks kdm, I'd like to see it create /run/kdm as mode 0711 -- I think that is the best solution (and gdm as well, although for some reason that is the case here which is against how the rpm would be installing it, since according to the spec it should be 1777 as well). Than, do you know why /run/kdm would be mode 1777, and does it need to be?
Changing the mode to 0711 is simple. But it doesn't fix the denial of service attack. gdm and kdm have the same problem, but limited to a single user account for the attack. As for expectation of /run - it doesn't matter. As long as it is shared with user files and MUST have available space for proper service activity, it can be used for a denial of service attack. ANY filesystem that a user can write to can be filled up. The only defense are per filesystem quota (and oversubscription must be disallowed). As long as the authority file can be updated (and that IS a requirement), the DOS attack exists. And I've already read the objections to Potterings attempt to hijack rlimit for limits on tmpfs (and personally, I believe Alan Cox is right). I strongly recommend putting it back in /var - or have a configuration option where the administrator can specify where it goes - A place where quotas can be imposed.
> > Than, do you know why /run/kdm would be mode 1777, and does it need to be? in f16 the auth files are saved in /run/kdm, the mode 1777 is needed for creating xauthrity file here. kdm doesn't work if /run/kdm is set as mode 0711. in f17, the auth files are saved in /tmp/kde-$user, so the /run/kdm mode 1777 is not needed and it can be set to 0711.
Gdm should do the same thing. It would eliminate the attack vector using user owned files in the /run filesystem.
(In reply to comment #14) > > > > Than, do you know why /run/kdm would be mode 1777, and does it need to be? > > in f16 the auth files are saved in /run/kdm, the mode 1777 is needed for > creating xauthrity file here. kdm doesn't work if /run/kdm is set as mode > 0711. > > in f17, the auth files are saved in /tmp/kde-$user, so the /run/kdm mode > 1777 is not needed and it can be set to 0711. Thanks for that info. Can we work towards doing that for kdm? We can clone this bug for gdm and do the same thing there as well.
I'll see about implementing the idea(s) from comment #14
kde-settings-4.9-15.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kde-settings-4.9-15.fc18
Package kde-settings-4.9-15.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kde-settings-4.9-15.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17798/kde-settings-4.9-15.fc18 then log in and leave karma (feedback).
After updating kde-settings in rawhide to kde-settings-19-9.fc19 I got error: Cannot create authorization file in /var/run/kdm: Permission denied /run/kdm have 711 permissions, when I set it to 777 KDE started, user .XauthzE6F7b file created in /run/kdm and xauth-500-0-_0 created in /tmp/kde-user.
On my box, kdm creates an xauth that looks like: /var/run/kdm/A:0-eYWoLa no idea where that .Xauth... one is coming from.
(In reply to comment #21) > On my box, kdm creates an xauth that looks like: > /var/run/kdm/A:0-eYWoLa This file owned by root and created before user login, no problem with its creation when /run/kdm have 711 permissions.
In F17 I don't have .Xauth* files in /run/kdm.
I don't know why in my rawhide system UserAuthDir was set to /var/run/kdm in /etc/kde/kdm/kdmrc but after I removed that line .Xauth* files created in /tmp.
Package kde-settings-4.9-15.fc18.1: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kde-settings-4.9-15.fc18.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17798/kde-settings-4.9-15.fc18.1 then log in and leave karma (feedback).
kde-settings-4.9-16.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kde-settings-4.9-16.fc18.1
kde-settings-4.9-16.fc18.1 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.