FS#10374 - [gdm] causes system to disobey /etc/security/limits.conf

Attached to Project: Arch Linux
Opened by name withheld (Gullible Jones) - Thursday, 08 May 2008, 18:44 GMT
Last edited by Jan de Groot (JGC) - Friday, 19 June 2009, 06:44 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity Critical
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

If GDM is used as a login manager, PAM stuff (including /etc/security/limits.conf) is not used. This makes the system vulnerable to forkbombs (and probably other hazards), as well as ruining realtime for users.

Because of the security risks here and since GDM might see use in office environments or on workstations, I'm flagging this critical.

Additional info:
* pam 1.0.1-1, gdm 2.20.1-2
* There's config stuff for gdm and gnome-screensaver in /etc/pam.d. It doesn't contain anything on limits.conf AFAICT, but it makes me think this may be solvable for Arch instead of requiring me to go upstream.

Steps to reproduce:

1. Set a limit on nproc in limits.conf.
2. Set up GDM as your login manager and use it to launch your desktop.
3. Open a terminal, run a forkbomb, and watch your system crash in spite of your limits.conf settings.
This task depends upon

Closed by  Jan de Groot (JGC)
Friday, 19 June 2009, 06:44 GMT
Reason for closing:  Not a bug
Additional comments about closing:  ulimit settings get applied by logins from gdm.
Comment by Aaron Griffin (phrakture) - Thursday, 08 May 2008, 18:51 GMT
If the config stuff is actually there, I wonder if we're just missing something as simple as a configure flag.
Comment by name withheld (Gullible Jones) - Thursday, 08 May 2008, 19:17 GMT
Maybe it has to be made executable? I did notice that all the stuff in pam.d was -x.
Comment by Jan de Groot (JGC) - Thursday, 08 May 2008, 21:30 GMT
This is because gdm doesn't include pam_limits.so in the supplied pam file.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 12:39 GMT
I'll try adding that and see how it works.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 12:40 GMT
Nope, pam_limits.so is definitely there.

#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so
account required pam_unix.so
session required pam_limits.so <-- requisite entry
session required pam_unix.so
password required pam_unix.so

Not nice.
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 12:52 GMT
Try putting pam_limits.so below pam_unix.so. If that works out, I'll fix it for the next gdm update.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 12:54 GMT
This is worse than I thought. Right now I'm using the CLI login, not GDM, and have nproc limited to 256; and a bash forkbomb still freezes my machine very quickly. It looks as though PAM stuff is being disobeyed across the board.
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 13:10 GMT
Please supply the /etc/security/limits.conf you're using. On my system, adding things to limits.conf works fine without problems.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 13:20 GMT
* hard maxlogins 4
* soft nproc 256
* hard nproc 512
* - rtprio 0
* - nice 0
@audio - rtprio 65
@audio - nice -10
@audio - memlock 40000
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 13:28 GMT
What does ulimit -a show after logging in?
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 16:57 GMT
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 30
file size (blocks, -f) unlimited
pending signals (-i) 4020
max locked memory (kbytes, -l) 40000
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 65
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 256 <--- Strange, that's what it's supposed to be. WTF?
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Comment by name withheld (Gullible Jones) - Tuesday, 03 June 2008, 23:07 GMT
Okay, I can confirm that rlimits stuff at least is not being obeyed. Recent experimentation with jackd as user got me this from a Wine sound test:

$ winecfg
cannot lock down memory for RT thread (Cannot allocate memory)

With this in limits.conf:

@audio - rtprio 80
@audio - nice -10
@audio - memlock 250000

There's definitely something fishy here.
Comment by name withheld (Gullible Jones) - Tuesday, 03 June 2008, 23:08 GMT
^^^ Also, I was starting jackd with the -R option, so that side of things was definitely correct.
Comment by name withheld (Gullible Jones) - Wednesday, 04 June 2008, 22:22 GMT
With rtprio 99 and nice -20, I'm still unable to use realtime. This is very bad.
Comment by Giulio Fidente (giulivo) - Saturday, 25 October 2008, 15:32 GMT
btw, pam is quite difficult to be correctly managed (and aligned) between all the applications; so what I think is that it would be nice to see a "generic" pam file imported (using the include keyword) by the others ... this way we could simply add the needed differences in the specific files saving us from a "module missing" in one or another pam config file. I think it would also simplify the management. fedora/redhat , for example , they do this way
Comment by Denis A. Altoe Falqueto (denisfalqueto) - Tuesday, 04 November 2008, 01:05 GMT
I'm using kde (in fact, kdemod4), and the /etc/pam.d/kde file contains pam_limits.so after pam_unix.so, as JGC suggests. And it _is_ working. It is reflecting my /etc/security/limits.conf file correctly. Have anyone tried that change for gdm? I don't have it installed here, so I can't check.
Comment by Ben Tartsa (leadghost) - Tuesday, 11 November 2008, 18:29 GMT
This error :

cannot lock down memory for RT thread (Cannot allocate memory)

was reported pretty commonly when doing realtime audio work w/ jackd and the latest kernel. It seems that some that some have resolved this issue by downgrading. I am running 2.6.24 w/ ingos rt21 patches and using the slim-pam package from AUR w/ proper results. Hope this is of use.
Comment by Ben Tartsa (leadghost) - Tuesday, 11 November 2008, 19:08 GMT
This error :

cannot lock down memory for RT thread (Cannot allocate memory)

was reported pretty commonly when doing realtime audio work w/ jackd and the latest kernel. It seems that some that some have resolved this issue by downgrading. I am running 2.6.24 w/ ingos rt21 patches and using the slim-pam package from AUR w/ proper results. Hope this is of use.
Comment by Rorschach (Rorschach) - Wednesday, 26 November 2008, 10:13 GMT
Just wanna add that rising memlocks with the help of the security-limits works fine here with slim-pam / gdm.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 03 June 2009, 21:22 GMT
what is the status of these issues?
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 19 June 2009, 01:17 GMT
OK I just tested this under gdm-2.20.10-1 (started from init) setting for example "djgera - nproc 1000" @ /etc/security/limits.conf login, then open a terminal ulimit -u show that the expected value is set.

So this issue, can be closed?

Loading...