Bug 830433 - /var/run/kdm allows users to fill the /run tmpfs filesystem with a file.
Summary: /var/run/kdm allows users to fill the /run tmpfs filesystem with a file.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-settings
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-09 14:30 UTC by Jesse Pollard
Modified: 2012-12-06 07:23 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-06 07:23:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jesse Pollard 2012-06-09 14:30:37 UTC
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.

Comment 1 Kevin Kofler 2012-06-11 22:04:57 UTC
Ugh, why is /var/run/kdm world-writable? Does it have to be?

Comment 2 Rex Dieter 2012-06-12 15:18:03 UTC
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

Comment 3 Jesse Pollard 2012-06-12 19:07:47 UTC
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.

Comment 4 Jesse Pollard 2012-06-12 19:15:02 UTC
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.

Comment 5 Jesse Pollard 2012-06-12 19:27:25 UTC
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).

Comment 6 Rex Dieter 2012-06-12 19:28:01 UTC
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

Comment 7 Rex Dieter 2012-06-12 19:28:58 UTC
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).

Comment 8 Jesse Pollard 2012-06-12 19:36:54 UTC
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.

Comment 9 Kevin Kofler 2012-06-12 22:53:56 UTC
Re comment #7 (Rex Dieter): Relying on SELinux to block this security vulnerability is a bad idea, not everyone has SELinux enabled.

Comment 10 Jesse Pollard 2012-06-13 11:51:16 UTC
Even then.

The DOS could just add keys to the authorization file until it fills the tmpfs.

Comment 11 Vincent Danen 2012-06-14 20:24:50 UTC
(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.

Comment 12 Vincent Danen 2012-06-14 20:52:13 UTC
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?

Comment 13 Jesse Pollard 2012-06-14 22:33:45 UTC
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.

Comment 14 Than Ngo 2012-06-18 14:37:41 UTC
> 
> 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.

Comment 15 Jesse Pollard 2012-06-18 17:26:16 UTC
Gdm should do the same thing.

It would eliminate the attack vector using user owned files in the /run filesystem.

Comment 16 Vincent Danen 2012-06-19 21:08:24 UTC
(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.

Comment 17 Rex Dieter 2012-10-22 19:42:03 UTC
I'll see about implementing the idea(s) from comment #14

Comment 18 Fedora Update System 2012-11-08 19:13:54 UTC
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

Comment 19 Fedora Update System 2012-11-09 03:18:44 UTC
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).

Comment 20 nucleo 2012-11-10 02:48:29 UTC
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.

Comment 21 Rex Dieter 2012-11-10 02:56:52 UTC
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.

Comment 22 nucleo 2012-11-10 02:59:59 UTC
(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.

Comment 23 nucleo 2012-11-10 03:18:22 UTC
In F17 I don't have .Xauth* files in /run/kdm.

Comment 24 nucleo 2012-11-10 03:26:44 UTC
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.

Comment 25 Fedora Update System 2012-11-13 19:09:56 UTC
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).

Comment 26 Fedora Update System 2012-11-27 14:43:41 UTC
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

Comment 27 Fedora Update System 2012-12-06 07:23:14 UTC
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.


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