Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I setup my environment to create a core dump of everything that crashes, however when I run an program with SUID set on a different user than the executing user it doesn't create a core dump. Any idea's why this might be? I couldn't find it anywhere on the web, I think it's some sort of security feature but I would like to have it disabled...

Problem:

$ cd /tmp
$ cat /etc/security/limits.conf | grep core
*     -     core     unlimited
root  -     core     unlimited

$ ls -l ohai
-rwsr-sr-x 1 root root 578988 2011-06-23 23:29 ohai

$ ./ohai
...
Floating point exception

$ sudo -i
# ./ohai
...
Floating point exception (core dumped)
# chmod -s ohai
# exit
$ ./ohai
...
Floating point exception (core dumped)

Edit: To make it work as secure as possible I now have the following script to setup the environment:

mkdir -p /var/coredumps/
chown root:adm /var/coredumps/
chmod 772 /var/coredumps/

echo "kernel.core_pattern = /var/coredumps/core.%u.%e.%p" >> /etc/sysctrl.conf
echo "fs.suid_dumpable = 2" >> /etc/sysctl.conf

echo -e "*\t-\tcore\tunlimited" >> /etc/security/limits.conf
echo -e "root\t-\tcore\tunlimited" >> /etc/security/limits.conf

Now all that's left to do is add ACL to /var/coredumps so users can only add files and don't modify nor read them ever again. The only downsize is that I would still have a problem with chroot'ed applications which would need a bind mount or something like that.

share|improve this question
up vote 16 down vote accepted

The memory of a setuid program might (is likely to, even) contain confidential data. So the core dump would have to be readable by root only.

If the core dump is owned by root, I don't see an obvious security hole, though the kernel would have to be careful not to overwrite an existing file.

Linux disables core dumps for setxid programs. To enable them, you need to do at least the following (I haven't checked that this is sufficient):

  • Enable setuid core dumps in general by setting the fs.suid_dumpable sysctl to 2, e.g. with echo 2 >/proc/sys/fs/suid_dumpable. (Note: 2, not 1; 1 means “I'm debugging the system as a whole and want to remove all security”.)
  • Call prctl(PR_SET_DUMPABLE, 1) from the program.
share|improve this answer
    
Sir, you are now my personal hero! – DipSwitch Jun 23 '11 at 22:51
    
@DipSwitch Strange, that's not what the documentation for fs.suid_dumpable says. Can you try setting fs.suid_dumpable without calling pctrl in the program? Maybe I'm misunderstanding the documentation and you do get a core but owned by root in this case. – Gilles Jun 23 '11 at 23:19
    
Ah crap my bad... the file is owned by root but the %u (uid) in core_pattern was fooling me at first sight. – DipSwitch Jun 23 '11 at 23:33
    
This solution also seems to apply to programs run under "sudo -s ", at least for kernel 2.6.27. – Seth Noble Nov 3 '15 at 16:25

I decided that I will also share my use case, until I forget it. It might be handy also for future me since I was solving same issue months ago and it took me too much time to find out once more. Ok. it is not actually core-dump, but stack trace that is also useful.

Problem: No idea what is going on there:

sudo id
Segmentation fault

Solution: Move suid bit from sudo to valgrind works fine:

chmod +s /usr/bin/valgrind
chmod -s /usr/bin/sudo
valgrind /usr/bin/sudo id

If debuginfo is installed, nice backtrace is written out.

share|improve this answer
    
And meanwhile, until you remember to reset persmissions, everybody and aunt Tillie can valgrind whatever they want. Don't do this, it is a huge security risk. – vonbrand Jan 29 at 16:38
    
only on testing machine and for testing purposes of course. – Jakuje Jan 29 at 16:40
    
gives me the willies, regardless. – vonbrand Jan 29 at 16:43

The core dump contains a copy of everything which was in memory at the time of the fault. If the program is running suid, that means it needs access to something which you, as a user, do not have access to. If the program gets that information then dumps core, you'll be able to read that privileged information.

From your example above, it appears that you're able to get a core dump when running as root or if you remove the privilege escalation.

While it might be handy (for developers only methinks) to have easy access to a coredump from a setuid program, it is a security hole, and should be left in place.

share|improve this answer
1  
I was afraid you where going to say something like that :( – DipSwitch Jun 23 '11 at 22:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.