pam_fscrypt probably locks too much memory #405
Comments
|
Someone smarter than me pointed out that this is most likely due to this function: If the other end that provides the pointer did not properly null terminate the string, Why it takes long at my side just to hit a random However, I'd suggest to use I acknowledge that the bug at my system is not |
|
Ya it looks like we are hitting an error here: Line 112 in 2bf4521 My guess is that we are being passed a malformed (or weirdly long) fscrypt/pam_fscrypt/pam_fscrypt.go Line 104 in 2bf4521 which then locks the memory here: Line 98 in 2bf4521 but note that we don't check the error code. Then, in fscrypt/pam_fscrypt/pam_fscrypt.go Line 228 in 2bf4521 So I think to address these issues we should:
We could also just stop manually locking things in memory inside of our PAM module. It does seem like locking buffers in memory has caused more issues than its solved. |
|
libpam treats PAM_AUTHTOK as a null-terminated string internally, e.g. when |
|
Thanks for getting back to this so fast. I have to confess, I didn't compile go for a while now. I guess I'd also need a few dev-dependencies to get my own I have no time for that extra mile atm., but I will look into that at the weekend. |
|
This got a little messy. I applied the patch, which lead to a situation where I could not log in, because my greeter froze as soon as I entered the password and tipped unlock. Fortunately I could log in via ssh and after that also use the greeter on the tablet. This probably just changed some mem layout circumventing the bug - at least I have no better idea. I was able to retrieve some logs: Note the I got curious and replaced the That got me nowhere because I wasn't printing the size, but I failed to copy the new I had to do some rescuing.
In the end I rewrote To my surprise the I reverted my lock-mem unlimiting again, to see were it actually crashes. That gave me some more interesting log: Looks like neither I hope this helps a bit. My guesses have been proven wrong. |
|
Just out of curiosity I replaced the This crashes the whole greeter the very moment I enter a password and falls back to console. Not even my new debug statements show up at journalctrl, instead I'm being left with only this line on the console: It still works with unlimited lock mem though. After having traced the string length and the mmap calls through the code like this, I no longer believe that this is a bug in I was mistaken by the ulimit being a per process property - but since Feel free to close this issue, I don't think there is anything that could be done about this on |
|
One last thing: I just rebuild with to have something that works on my machine with default values, being pretty sure that the keys will never be swapped at boot time anyway. I still get This is above my head. |
|
I just could not stop it. To get rid of replacing the This again still requires max locked memory to be set to unlimited to work, but it crashes in an interesting way if normal limits are applied. It dies in argon2 while trying to allocate a This makes me wonder if for some reason all allocations here count against the maximum locked memory limit. Something about memory management is rotten here. Without This still may be some weird side-effect of using mobians greeter, but I can't use it like this and it appears I also can not debug it. |
|
@ebiggers I have a new hypothesis, I wonder if some PAM configuration is causing all allocated memory to be locked, including that in the Argon2 passphrase hash. Do you think that's possible? |
On my tablet which runs mobian (so basically debian) I have some folders I want to unlock at login.
Therefore I use
pam_fscrypt.For a long time this did not work, so I had to run
fscrypt unlockmanually after login. That worked, so the setup is correct so far.Running
pam_fscryptwithdebugparameter revealed that it fails to lock memory for AUTHTOK in one place and as a result fails to fetch the token in another.Here's the output of
journalctl -b | fgrep fscryptWhen I raise the limit in
/etc/security/limits.conftounlimited(I don't really care here), it works.This is debug info from a successful run:
Here are the default hard- and softlimits for
max locked memory(read as "if I don't set it tounlimited")If I understood that correctly this is per process and in kilobytes. To exceed that one would need to lock
~961Mib?I think that's unreasonable for
pam_fscryptto do in every plausible circumstance.The text was updated successfully, but these errors were encountered: