It looks like that there are no opponents of this change but several
supporters
and few of them even want to have suid_dumpable=2 in all releases.
I was thinking about it and Richard W.M. Jones' email about safeness of
suid_dumpable=2 without ABRT gave me an idea to teach ABRT to set
suid_dumpable=2 in abrt-ccpp.service. The service sets kernel.core_pattern
(/proc/sys/kernel/core_pattern) to ABRT pattern, so it could also update
suid_dumpable. If an administrator uninstalls/turns off ABRT, suid_dumpable
would get back the OS default value. If he/she modifies core_pattern by
hand,
then he/she is skilled enough to spot kernel warning in the logs.
What do you think about it?
I would especially like to hear thoughts on this from security experts.
Do I need to get any permission to do so?
Regards,
Jakub
On 02/12/2016 01:24 PM, Jakub Filak wrote:
----- Forwarded Message -----
From: "Jakub Filak" <jfilak@xxxxxxxxxx>
To: security@xxxxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, February 11, 2016 9:51:04 AM
Subject: Use suid_dumpable=2 for development releases
Hello,
As a maintainer of ABRT, I have been asked several times why ABRT does not catch
crashes of many processes and one kind of reasons dominate among other reasons
- processes that executes set-user-ID programs (man 5 core). These processes
are not dumped at all if the value of /proc/sys/fs/suid_dumpable is 0 (man 5
proc) which is the default value. With the default suid_dumpable
value, crashes caused by SIGABRT are not detectable because kernel doesn't even
write a log message about that.
The default value 0 is there for good security reason, but I would like to
propose changing the default value to 2 for development Fedora releases (Alpha,
Beta, Rawhide). In this case, kernel would send core dump to ABRT (or
systemd-coredump) and the ABRT record would be accessible only to root.
I believe that maintainers of packages like chrony will be really delighted
with this change, while will not weaken security of Fedora for regular users.
Regards,
Jakub
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/security@xxxxxxxxxxxxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
