From: Dmitry Vyukov <dvyukov@google.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
Dmitry Vyukov <dvyukov@google.com>,
syzbot <syzbot+85da7ac734f7ba432ee4@syzkaller.appspotmail.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: WARNING in ext4_invalidatepage
Date: Tue, 30 Oct 2018 13:16:11 +0100 [thread overview]
Message-ID: <CACT4Y+b3rujNu+kJFaEmZzwOWSHuFYpYVJ4q3vvY62FtQ8+7xA@mail.gmail.com> (raw)
In-Reply-To: <20181016155341.GF8983@thunk.org>
On Tue, Oct 16, 2018 at 5:53 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>> > The patch I referenced in my previous e-mail protects against
>> > additional scenarios where someone might be trying to punch a whole
>> > into a file that is being swapped into the bootloader ioctl. This
>> > particular ioctl isn't yet being used by anyone, so it had some other
>> > issues as well, such as not interacting well with inline_data-enabled
>> > file systems --- not that any bootloader would be small enough that it
>> > would fit in an inline_data inode, but we're basically proofing the
>> > code against a malicious (or buggy) root-privileged program... such as
>> > syzbot. :-)
>>
>> ... or paving the way to opening all of this to non-root users. Why
>> not if not bugs? ;)
>
> The intent behind this particular ioctl is used to install a boot
> loader. It will *never* be opened to non-root users. It doesn't even
> make sense to make it available to pseudo-containers-root users. :-)
But it does not have to be executed on the root fs, right? Or is it?
For example, if I need to build a bootable image (which I actually
need to do for syzkaller). In the end it boils down to just creating a
local, private file with some particular contents. Should be nobody's
business, right? But for some reason on Linux creation of a local file
requires root privileges multiple times along the way. As the result I
have run the whole service as root, degrading overall security. And I
can't say that I fully trust all code and data involved, but Linux
simply does not give me any choice.
prev parent reply other threads:[~2018-10-30 12:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-08 16:18 WARNING in ext4_invalidatepage syzbot
2018-10-08 16:29 ` Dmitry Vyukov
2018-10-09 1:34 ` Theodore Y. Ts'o
2018-10-15 13:22 ` Dmitry Vyukov
2018-10-15 18:08 ` Theodore Y. Ts'o
2018-10-16 14:02 ` Dmitry Vyukov
2018-10-16 15:53 ` Theodore Y. Ts'o
2018-10-30 12:09 ` Dmitry Vyukov
2018-10-30 12:16 ` Dmitry Vyukov [this message]
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=CACT4Y+b3rujNu+kJFaEmZzwOWSHuFYpYVJ4q3vvY62FtQ8+7xA@mail.gmail.com \
--to=dvyukov@google.com \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+85da7ac734f7ba432ee4@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tytso@mit.edu \
/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.