Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1566954 > unrolled thread
| Started by | Andy Lutomirski <luto@kernel.org> |
|---|---|
| First post | 2017-01-25 22:10 +0100 |
| Last post | 2017-01-26 01:10 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] setgid hardening Andy Lutomirski <luto@kernel.org> - 2017-01-25 22:10 +0100
Re: [PATCH 0/2] setgid hardening Willy Tarreau <w@1wt.eu> - 2017-01-26 01:10 +0100
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-01-25 22:10 +0100 |
| Subject | [PATCH 0/2] setgid hardening |
| Message-ID | <t3CZk-6Zx-21@gated-at.bofh.it> |
The kernel has some dangerous behavior involving the creation and modification of setgid executables. These issues aren't kernel security bugs per se, but they have been used to turn various filesystem permission oddities into reliably privilege escalation exploits. See http://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/ for a nice writeup. Let's fix them for real. Andy Lutomirski (2): fs: Check f_cred instead of current's creds in should_remove_suid() fs: Harden against open(..., O_CREAT, 02777) in a setgid directory fs/inode.c | 37 ++++++++++++++++++++++++++++++------- fs/internal.h | 2 +- fs/ocfs2/file.c | 4 ++-- fs/open.c | 2 +- include/linux/fs.h | 2 +- 5 files changed, 35 insertions(+), 12 deletions(-) -- 2.9.3
[toc] | [next] | [standalone]
| From | Willy Tarreau <w@1wt.eu> |
|---|---|
| Date | 2017-01-26 01:10 +0100 |
| Message-ID | <t3FNv-iY-7@gated-at.bofh.it> |
| In reply to | #1566954 |
On Wed, Jan 25, 2017 at 01:06:50PM -0800, Andy Lutomirski wrote: > The kernel has some dangerous behavior involving the creation and > modification of setgid executables. These issues aren't kernel > security bugs per se, but they have been used to turn various > filesystem permission oddities into reliably privilege escalation > exploits. > > See http://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/ > for a nice writeup. > > Let's fix them for real. BTW I like this. I vaguely remember having played with this when I was a student 2 decades ago on a system where /var/spool/mail was 3777 (yes, setgid+sticky) and the mail files were 660. You could deposit a shell there, then execute it with mail's permissions and access any mailbox. That was quite odd as a design choice. The impacts are often limited unless you find other ways to escalate but generally it's not really clean. Willy
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web