From: Matthew Wilcox <willy@infradead.org>
To: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
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: Wed, 22 Nov 2017 05:22:36 -0800 [thread overview]
Message-ID: <20171122132235.GA30635@bombadil.infradead.org> (raw)
In-Reply-To: <1511337706-8297-3-git-send-email-s.mesoraca16@gmail.com>
On Wed, Nov 22, 2017 at 09:01:46AM +0100, Salvatore Mesoraca wrote:
> +An O_CREAT open missing the O_EXCL flag in a sticky directory is,
> +often, a bug or a synthom of the fact that the program is not
> +using appropriate procedures to access sticky directories.
> +This protection allow to detect and possibly block these unsafe
> +open invocations, even if the files don't exist yet.
> +Though should be noted that, sometimes, it's OK to open a file
> +with O_CREAT and without O_EXCL (e.g. shared lock files based
> +on flock()), for this reason values above 2 should be set
> +with care.
> +
> +When set to "0" the protection is disabled.
> +
> +When set to "1", notify about O_CREAT open missing the O_EXCL flag
> +in world writable sticky directories.
> +
> +When set to "2", notify about O_CREAT open missing the O_EXCL flag
> +in world or group writable sticky directories.
> +
> +When set to "3", block O_CREAT open missing the O_EXCL flag
> +in world writable sticky directories and notify (but don't block)
> +in group writable sticky directories.
> +
> +When set to "4", block O_CREAT open missing the O_EXCL flag
> +in world writable and group writable sticky directories.
This seems insufficiently flexible. For example, there is no way for me
to specify that I want to block O_CREAT without O_EXCL in world-writable,
but not be notified about O_CREAT without O_EXCL in group-writable.
And maybe I want to be notified that blocking has happened?
Why not make it bits? So:
0 => notify in world
1 => block in world
2 => notify in group
3 => block in group
So you'd have the following meaningful values:
0 - permit all (your option 0)
1 - notify world; permit group (your option 1)
2 - block world; permit group
3 - block,notify world; permit group
4 - permit world; notify group (?)
5 - notify world; notify group (your option 2)
6 - block world; notify group (your option 3)
7 - block,notify world; notify group
8 - permit world; block group (?)
9 - notify world; block group (?)
10 - block world; block group (your option 4)
11 - block,notify world; block group
12 - permit world; block, notify group (?)
13 - notify world; block, notify group (?)
14 - block world; block, notify group
15 - block, notify world; block, notify group
Some of these don't make a lot of sense (marked with ?), but I don't see
the harm in permitting a sysadmin to do something that seems nonsensical
to me.
next prev parent reply other threads:[~2017-11-22 13:22 UTC|newest]
Thread overview: 26+ 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 ` [PATCH v3 1/2] Protected FIFOs and regular files Salvatore Mesoraca
2017-11-23 22:43 ` [kernel-hardening] " 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 13:22 ` Matthew Wilcox [this message]
2017-11-24 8:29 ` Salvatore Mesoraca
2017-11-22 16:51 ` Alan Cox
2017-11-24 8:31 ` Salvatore Mesoraca
2017-11-24 10:53 ` David Laight
2017-11-24 11:43 ` Salvatore Mesoraca
2017-11-24 11:53 ` David Laight
2017-11-26 11:29 ` Salvatore Mesoraca
2017-11-27 0:26 ` Solar Designer
2017-11-30 14:39 ` Salvatore Mesoraca
2017-11-30 14:57 ` [kernel-hardening] " 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 17:51 ` Solar Designer
2017-12-01 9:46 ` David Laight
2017-12-01 15:52 ` Alan Cox
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=20171122132235.GA30635@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=ebiederm@xmission.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).