All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Salvatore Mesoraca'" <s.mesoraca16@gmail.com>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
	"Solar Designer" <solar@openwall.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories
Date: Fri, 24 Nov 2017 11:53:01 +0000	[thread overview]
Message-ID: <d1ffc1cd48b545ebb81a7f682fde9f1d@AcuMS.aculab.com> (raw)
In-Reply-To: <CAJHCu1K-xZXaXh38qYaNzJBr+USVxvsaqOReZjtnchxVOyYnww@mail.gmail.com>

From: Salvatore Mesoraca [mailto:s.mesoraca16@gmail.com]
> Sent: 24 November 2017 11:44
> 
> 2017-11-24 11:53 GMT+01:00 David Laight <David.Laight@aculab.com>:
> > From: Alan Cox
> >> Sent: 22 November 2017 16:52
> >>
> >> On Wed, 22 Nov 2017 09:01:46 +0100
> >> Salvatore Mesoraca <s.mesoraca16@gmail.com> wrote:
> >>
> >> > Disallows O_CREAT open missing the O_EXCL flag, in world or
> >> > group writable directories, even if the file doesn't exist yet.
> >> > With few exceptions (e.g. shared lock files based on flock())
> >>
> >> Enough exceptions to make it a bad idea.
> >>
> >> Firstly if you care this much *stop* having shared writable directories.
> >> We have namespaces, you don't need them. You can give every user their
> >> own /tmp etc.
> >
> > Looks like a very bad idea to me as well.
> >
> > Doesn't this stop all shell redirects into a shared /tmp ?
> > I'm pretty sure most programs use O_CREAT | O_TRUNC for output
> > files - they'll all stop working.
> 
> If some program does such a thing, that's a potential vulnerability.
> With "protected_hardlinks" you are, in most cases, safe.
> But, still, that program has a bug and having this feature enabled will
> help you notice it soon.
> For that matter, I'm using this patch on my system and I don't have any
> program behaving like this.

Hmmm.... a quick strace shows cp and vi doing stat("/tmp/foo") and then
open(O_WRONLY|O_TRUNC) if it exists and O_CREATE|O_EXCL if it doesn't.
I can't help feeling that is just hiding a race.

	David

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Salvatore Mesoraca' <s.mesoraca16@gmail.com>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
	Solar Designer <solar@openwall.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [kernel-hardening] RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories
Date: Fri, 24 Nov 2017 11:53:01 +0000	[thread overview]
Message-ID: <d1ffc1cd48b545ebb81a7f682fde9f1d@AcuMS.aculab.com> (raw)
In-Reply-To: <CAJHCu1K-xZXaXh38qYaNzJBr+USVxvsaqOReZjtnchxVOyYnww@mail.gmail.com>

From: Salvatore Mesoraca [mailto:s.mesoraca16@gmail.com]
> Sent: 24 November 2017 11:44
> 
> 2017-11-24 11:53 GMT+01:00 David Laight <David.Laight@aculab.com>:
> > From: Alan Cox
> >> Sent: 22 November 2017 16:52
> >>
> >> On Wed, 22 Nov 2017 09:01:46 +0100
> >> Salvatore Mesoraca <s.mesoraca16@gmail.com> wrote:
> >>
> >> > Disallows O_CREAT open missing the O_EXCL flag, in world or
> >> > group writable directories, even if the file doesn't exist yet.
> >> > With few exceptions (e.g. shared lock files based on flock())
> >>
> >> Enough exceptions to make it a bad idea.
> >>
> >> Firstly if you care this much *stop* having shared writable directories.
> >> We have namespaces, you don't need them. You can give every user their
> >> own /tmp etc.
> >
> > Looks like a very bad idea to me as well.
> >
> > Doesn't this stop all shell redirects into a shared /tmp ?
> > I'm pretty sure most programs use O_CREAT | O_TRUNC for output
> > files - they'll all stop working.
> 
> If some program does such a thing, that's a potential vulnerability.
> With "protected_hardlinks" you are, in most cases, safe.
> But, still, that program has a bug and having this feature enabled will
> help you notice it soon.
> For that matter, I'm using this patch on my system and I don't have any
> program behaving like this.

Hmmm.... a quick strace shows cp and vi doing stat("/tmp/foo") and then
open(O_WRONLY|O_TRUNC) if it exists and O_CREATE|O_EXCL if it doesn't.
I can't help feeling that is just hiding a race.

	David


  reply	other threads:[~2017-11-24 11:52 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  8:01 [PATCH v3 0/2] Restrict dangerous open in sticky directories Salvatore Mesoraca
2017-11-22  8:01 ` [kernel-hardening] " Salvatore Mesoraca
2017-11-22  8:01 ` [PATCH v3 1/2] Protected FIFOs and regular files Salvatore Mesoraca
2017-11-22  8:01   ` [kernel-hardening] " Salvatore Mesoraca
2017-11-23 22:43   ` Tobin C. Harding
2017-11-24  8:24     ` Salvatore Mesoraca
2017-11-22  8:01 ` [PATCH v3 2/2] Protected O_CREAT open in sticky directories Salvatore Mesoraca
2017-11-22  8:01   ` [kernel-hardening] " Salvatore Mesoraca
2017-11-22 12:03   ` Pavel Vasilyev
2017-11-24  8:28     ` Salvatore Mesoraca
2017-11-22 13:22   ` Matthew Wilcox
2017-11-22 13:22     ` [kernel-hardening] " Matthew Wilcox
2017-11-22 14:38     ` Pavel Vasilyev
2017-11-24  8:29     ` Salvatore Mesoraca
2017-11-24  8:29       ` [kernel-hardening] " Salvatore Mesoraca
2017-11-22 16:51   ` Alan Cox
2017-11-22 16:51     ` [kernel-hardening] " Alan Cox
2017-11-24  8:31     ` Salvatore Mesoraca
2017-11-24  8:31       ` [kernel-hardening] " Salvatore Mesoraca
2017-11-24 10:53     ` David Laight
2017-11-24 10:53       ` [kernel-hardening] " David Laight
2017-11-24 11:43       ` Salvatore Mesoraca
2017-11-24 11:43         ` [kernel-hardening] " Salvatore Mesoraca
2017-11-24 11:53         ` David Laight [this message]
2017-11-24 11:53           ` [kernel-hardening] " David Laight
2017-11-26 11:29           ` Salvatore Mesoraca
2017-11-26 11:29             ` [kernel-hardening] " Salvatore Mesoraca
2017-11-27  0:26         ` Solar Designer
2017-11-27  0:26           ` [kernel-hardening] " Solar Designer
2017-11-30 14:39           ` Salvatore Mesoraca
2017-11-30 14:39             ` [kernel-hardening] " Salvatore Mesoraca
2017-11-30 14:57             ` Ian Campbell
2017-11-30 16:30               ` [kernel-hardening] " Solar Designer
2017-12-05 10:21                 ` Salvatore Mesoraca
2017-12-07 21:47                   ` Solar Designer
2017-12-11 12:08                     ` Salvatore Mesoraca
2017-11-23 22:57   ` Tobin C. Harding
2017-11-24  8:34     ` Salvatore Mesoraca
2017-11-30 16:53   ` David Laight
2017-11-30 16:53     ` [kernel-hardening] " David Laight
2017-11-30 17:51     ` Solar Designer
2017-11-30 17:51       ` [kernel-hardening] " Solar Designer
2017-12-01  9:46       ` David Laight
2017-12-01  9:46         ` [kernel-hardening] " David Laight
2017-12-01 15:52         ` Alan Cox
2017-12-01 15:52           ` [kernel-hardening] " Alan Cox
2017-11-27  1:14 ` [kernel-hardening] Re: [PATCH v3 0/2] Restrict dangerous " Solar Designer
2017-11-27 13:18   ` Solar Designer
2017-11-30 14:38     ` Salvatore Mesoraca
2017-11-30 14:37   ` Salvatore Mesoraca
2017-11-30 19:05     ` Solar Designer
2017-11-30 19:14       ` Solar Designer
2017-12-05 10:13       ` Salvatore Mesoraca
2017-12-07 22:23         ` Solar Designer
2017-12-08 12:17           ` Solar Designer
2017-12-11 12:07             ` Salvatore Mesoraca
2017-12-11 15:33               ` Solar Designer
2017-12-12 18:00                 ` Salvatore Mesoraca
2017-12-11 16:07           ` Solar Designer
2017-12-12 18:01             ` Salvatore Mesoraca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1ffc1cd48b545ebb81a7f682fde9f1d@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=ebiederm@xmission.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.mesoraca16@gmail.com \
    --cc=solar@openwall.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.