Summary: | net-irc/unrealircd-3.2.7-r2 failed to load commands.so on startup | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Frederick <cdf123> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | coollyude, hardened, jdhore, kensington, kripton, mimosinnet, net-irc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | https://bugs.unrealircd.org/view.php?id=3705 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
strace of /usr/bin/unrealircd run as unrealircd user
unrealircd-3.2.7-r2-notmpmods.patch - disables copying modules before loading |
Description
Chris Frederick
2008-05-27 12:56:25 UTC
Seems to be a hardened problem. Try strace.. Created attachment 154485 [details]
strace of /usr/bin/unrealircd run as unrealircd user
open("tmp/C30FF564.commands.so", O_RDONLY) = 3 ... mmap2(NULL, 476256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = -1 EACCES (Permission denied) This looks to me to have nothing to do with hardened really but rather due to your nonexec dirs. Ie you can't mmap() with PROT_EXEC from a dir thats mounted with noexec. The .so might also lack a +x bit. Notice the invalid cross links. The noexec flag for /tmp has been in place for over a year, and physically moved the server between offices in that time so it shouldn't be causing the problem. Plus, if the noexec was the problem, why does it work when running it as root instead of the unrealircd user. In my understanding, noexec doesn't care what user you are, and that's part of it's benefit... It looks like the main module that is loaded does have the execute bit, but I can't tell on the /tmp copy. Those are created and cleaned faster than I know how to check. # ls -l /usr/lib/unrealircd/modules/commands.so -rwxr-xr-x 1 root root 434832 May 27 07:06 /usr/lib/unrealircd/modules/commands.so I disabled tpe in /proc/sys/grsecurity/tpe and that allows me to execute the /usr/bin/unrealircd program as the unrealircd user. If I had to guess, I'd say the /tmp/[rand].commands.so copy of the file is owned by the unrealircd user and that gets blocked by the tpe options. Is there some way to disable copying the *.so files to /tmp before loading them? Or is there a patch that will do this? (In reply to comment #8) > I disabled tpe in /proc/sys/grsecurity/tpe and that allows me to execute the > /usr/bin/unrealircd program as the unrealircd user. If I had to guess, I'd say > the /tmp/[rand].commands.so copy of the file is owned by the unrealircd user > and that gets blocked by the tpe options. > > Is there some way to disable copying the *.so files to /tmp before loading > them? Or is there a patch that will do this? > As a workaround you can configure the kernel to exclude a group from TPE restrictions. Otherwise looks like a design issue to be taken up with upstream imo. Leaving comments/decisions on this bug to solar though. Created attachment 154757 [details, diff]
unrealircd-3.2.7-r2-notmpmods.patch - disables copying modules before loading
I don't like the idea of adding a daemon user to the tpe trusted group, that isn't an option for me.
I've dug around the code a bit and created the attached patch and an overlay ebuild that applies the patch. It seems to work ok on a test machine, I'm going to update the production machine and test it there tomorrow. Can this be forwarded to a maintainer and/or upstream to verify that the patch is ok? I'd like to verify that by not copying the modules it won't cause other problems.
Chris, Can you personally take your patch to the upstream maintainers? That is the great thing about FOSS. Everybody shares. Added to unrealircd's bug tracking system under their gentoo patch review thread. http://bugs.unrealircd.org/view.php?id=3705 Sorry about the delay. I'll mark the bug as UPSTEAM as soon as I get a confirmation from them. (In reply to comment #4) > This looks to me to have nothing to do with hardened really but rather due to > your nonexec dirs. Ie you can't mmap() with PROT_EXEC from a dir thats mounted > with noexec. > This. First, I wanted to point out that the temporary .so is not stored in /tmp, but rather /etc/unrealircd/tmp, which by default is a symlink to /var/lib/unrealircd. Anyway, I reproduced this and got the same original failure but only when I remounted my /var as noexec. If you have a similar setup, I would assume that's the problem and nothing to do with tpe, however I question this as you said it worked fine for you as root. Also invalid cross link errors should be normal if Unreal's /etc and /var are on separate partitions. (In reply to comment #9) > As a workaround you can configure the kernel to exclude a group from TPE > restrictions. Otherwise looks like a design issue to be taken up with upstream > imo. As the patch has not been taken upstream, I have followed Gordon suggestion. This is my rellevant kernel config: CONFIG_GRKERNSEC_TPE=y CONFIG_GRKERNSEC_TPE_ALL=y CONFIG_GRKERNSEC_TPE_INVERT=y CONFIG_GRKERNSEC_TPE_GID=10 and I have added unrealircd to the wheel group. I am now able to start and stop unrealircd. Thanks! Is this reproducible on unrealircd-3.2.9 ? If not, I think this bug should be RESOLVED INVALID . (In reply to comment #15) > Is this reproducible on unrealircd-3.2.9 ? If not, I think this bug should > be RESOLVED INVALID . I don’t think unrealircd has changed its module loading strategy. I don’t have a hardened system to test this on; maybe I should, maybe Gentoo should patch UnrealIRCd to act more like a system daemon and stop copying module files around. This is cannot be fixed for the same reasons as upstream explained: https://bugs.unrealircd.org/view.php?id=3705 |