----- Forwarded Message ----- From: "Jakub Filak" jfilak@redhat.com To: security@lists.fedoraproject.org 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
On 12/02/16 12:24, Jakub Filak wrote:
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.
What part of chrony is setuid? I don't see an suid bit on any of it's executables... Nor any file capabilities which is the other thing the manual page says triggers this.
Tom
On Fri, Feb 12, 2016 at 12:40:37PM +0000, Tom Hughes wrote:
On 12/02/16 12:24, Jakub Filak wrote:
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.
What part of chrony is setuid? I don't see an suid bit on any of it's executables... Nor any file capabilities which is the other thing the manual page says triggers this.
The chrony files don't have any set*id bits set, but the chronyd process, like many other daemons, calls setuid()/setgid() in order to drop root privileges. The proc(5) man page lists that as a reason for not producing a coredump.
I was wondering what security implications would setting suid_dumpable to 2 by default had and why it needs to be restricted to development.
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote:
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.
It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path.
Ref: https://lwn.net/Articles/503682/
That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable.
The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice.
(I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.)
Rich.
On Fri, Feb 12, 2016 at 10:32 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote:
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.
It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path.
Ref: https://lwn.net/Articles/503682/
That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable.
The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice.
(I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.)
We could change the kernel to add suid_dumpable == 3 which is like suid_dumpable==2 but only if the core_pattern is a pipe.
--Andy
On 02/12/2016 07:57 PM, Andrew Lutomirski wrote:
On Fri, Feb 12, 2016 at 10:32 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote:
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.
It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path.
Ref: https://lwn.net/Articles/503682/
That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable.
The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice.
(I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.)
We could change the kernel to add suid_dumpable == 3 which is like suid_dumpable==2 but only if the core_pattern is a pipe.
I didn't know that 3 is supported for suid_dumpable. The value of 3 is not documented [1] and I can't find it in the source code [2].
Regards, Jakub
1: http://man7.org/linux/man-pages/man5/proc.5.html 2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include...
On Mon, 15 Feb 2016 07:00:36 +0100, Jakub Filak wrote:
On 02/12/2016 07:57 PM, Andrew Lutomirski wrote:
We could change the kernel to add suid_dumpable == 3 which is like suid_dumpable==2 but only if the core_pattern is a pipe.
I didn't know that 3 is supported for suid_dumpable. The value of 3 is not documented [1] and I can't find it in the source code [2].
It isn't. What he's saying is that option could be added.
On 02/12/2016 07:57 PM, Andrew Lutomirski wrote:
On Fri, Feb 12, 2016 at 10:32 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote:
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.
It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path.
Ref: https://lwn.net/Articles/503682/
That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable.
The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice.
(I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.)
We could change the kernel to add suid_dumpable == 3 which is like suid_dumpable==2 but only if the core_pattern is a pipe.
Starting with systemd-229 the default core_pattern has been changed to "|/bin/false" [1], hence, if an user uninstall ABRT or disable abrt-ccpp.service, the core_pattern will be either "|/bin/false" or "|/usr/lib/systemd/systemd-coredump ...". Thus the only case where core_patter can contain a string not starting with pipe is when admin changes it manually ("sysctl kernel.core_pattern ...", "echo ... > /proc/sys/kernel/core_pattern", etc).
Taking into account this new fact, do we still need to change the kernel?
Regards, Jakub
1: https://github.com/systemd/systemd/commit/15a900327aba7dc4dc886affe1ae22d3b7...
The issue described in the article was fixed by requiring an absolute path in core_pattern (If I understand it correctly).
If core_pattern is unsafe, the process is not dumped at all (man 5 proc).
The kernel commit adds a warning, because kernel was silently ignoring crashes and no one could notice.
Regards, Jakub
On 02/12/2016 07:32 PM, Richard W.M. Jones wrote:
On Fri, Feb 12, 2016 at 07:24:06AM -0500, Jakub Filak wrote:
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.
It seems like this would be unsafe if core_pattern is not a pipe or fully qualified path.
Ref: https://lwn.net/Articles/503682/
That's fine when ABRT is running, but would be unsafe if someone disabled ABRT by directly setting core_pattern (eg. to "core.%p"), but forgot about suid_dumpable.
The kernel does emit KERN_WARNING about this situation (upstream commit 54b501992dd2), but it's not clear if a sysadmin would notice.
(I'm actually quite happy for the default to be changed as you suggest, but can see it's a bit of a minefield.)
Rich.
The issue described in the article was fixed by requiring an absolute path in core_pattern (If I understand it correctly).
If core_pattern is unsafe, the process is not dumped at all (man 5 proc).
The kernel commit adds a warning, because kernel was silently ignoring crashes and no one could notice.
If this is true, shouldn't we be safe to set the default to 2?
Note also, that having suid_dumpable = 0 is sometimes blocking other security features in Fedora, for example sssd running as non-root by default - https://bugzilla.redhat.com/show_bug.cgi?id=1212503
Regards, /M
Regards, Jakub
On 02/12/2016 07:32 PM, Richard W.M. Jones wrote:
I'm not a security expert but I would rather start with something less ambitious and more secure. Just for sure.
Regards, Jakub
On 02/15/2016 11:22 AM, Miroslav Vadkerti wrote:
The issue described in the article was fixed by requiring an absolute path in core_pattern (If I understand it correctly).
If core_pattern is unsafe, the process is not dumped at all (man 5 proc).
The kernel commit adds a warning, because kernel was silently ignoring crashes and no one could notice.
If this is true, shouldn't we be safe to set the default to 2?
Note also, that having suid_dumpable = 0 is sometimes blocking other security features in Fedora, for example sssd running as non-root by default - https://bugzilla.redhat.com/show_bug.cgi?id=1212503
Regards, /M
Regards, Jakub
On 02/12/2016 07:32 PM, Richard W.M. Jones wrote:
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
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@redhat.com To: security@lists.fedoraproject.org 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Feb 15, 2016 10:36 PM, "Jakub Filak" jfilak@redhat.com wrote:
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?
This idea makes me very nervous. I would *much* rather that the kernel be changed.
Also, is ABRT itself safe? That is, if an unprivileged user starts, say, passwd and forces a coredump, can that user convince ABRT to show them the core file?
--Andy
Regards, Jakub
On 02/12/2016 01:24 PM, Jakub Filak wrote:
----- Forwarded Message ----- From: "Jakub Filak" jfilak@redhat.com To: security@lists.fedoraproject.org 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 02/16/2016 03:23 PM, Andrew Lutomirski wrote:
On Feb 15, 2016 10:36 PM, "Jakub Filak" <jfilak@redhat.com mailto:jfilak@redhat.com> wrote:
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?
This idea makes me very nervous.
I understand your concerns and I am happy someone else expressed it this way. I was asked several times to make suid_dumpable=2 by default last year and I always replied like you.
I would *much* rather that the kernel be changed.
Just for the clarification: you want to change suid_dumpable in kernel package or introduce the value of 3 or both?
Also, is ABRT itself safe?
We believe it is. But frankly we had several CVEs last year. However those CVEs helped us to make ABRT much safer. Florian Weimer went through the code base and found several issues that we have fixed. The CVEs are the reason why I didn't start this discussion sooner.
That is, if an unprivileged user starts, say, passwd and forces a coredump, can that user convince ABRT to show them the core file?
That user cannot convince ABRT to show them the core file. Only privileged users will have access to the core file.
Jakub
--Andy
Regards, Jakub
On 02/12/2016 01:24 PM, Jakub Filak wrote:
----- Forwarded Message ----- From: "Jakub Filak" <jfilak@redhat.com mailto:jfilak@redhat.com> To: security@lists.fedoraproject.org
mailto:security@lists.fedoraproject.org
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@lists.fedoraproject.org
mailto:security@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
-- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
-- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
-
Andrew Clayton -
Andrew Lutomirski -
Jakub Filak -
Miroslav Lichvar -
Miroslav Vadkerti -
Richard W.M. Jones -
Tom Hughes