Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-security-module <linux-security-module@vger.kernel.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	David Miller <davem@davemloft.net>,
	Al Viro <viro@zeniv.linux.org.uk>, bpf <bpf@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Gary Lin <GLin@suse.com>, Bruno Meneguele <bmeneg@redhat.com>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained
Date: Wed, 10 Jun 2020 09:24:35 -0700
Message-ID: <ba722761-ae29-9f1d-b851-ee2b75e0bb91@schaufler-ca.com> (raw)
In-Reply-To: <c9828709-c8e1-06a2-8643-e09e2e555b81@i-love.sakura.ne.jp>

On 6/10/2020 12:30 AM, Tetsuo Handa wrote:
> Forwarding to LSM-ML. Security people, any comments?
>
> On 2020/06/10 12:32, Alexei Starovoitov wrote:
>> On Wed, Jun 10, 2020 at 12:08:20PM +0900, Tetsuo Handa wrote:
>>> On 2020/06/10 9:05, Alexei Starovoitov wrote:
>>>> I think you're still missing that usermode_blob is completely fs-less.
>>>> It doesn't need any fs to work.
>>> fork_usermode_blob() allows usage like fork_usermode_blob("#!/bin/sh").
>>> A problem for LSMs is not "It doesn't need any fs to work." but "It can access any fs and
>>> it can issue arbitrary syscalls.".
>>>
>>> LSM modules switch their security context upon execve(), based on available information like
>>> "What is the !AT_SYMLINK_NOFOLLOW pathname for the requested program passed to execve()?",
>>> "What is the AT_SYMLINK_NOFOLLOW pathname for the requested program passed to execve()?",
>>> "What are argv[]/envp[] for the requested program passed to execve()?", "What is the inode's
>>> security context passed to execve()?" etc. And file-less execve() request (a.k.a.
>>> fork_usermode_blob()) makes pathname information (which pathname-based LSMs depend on)
>>> unavailable.
>>>
>>> Since fork_usermode_blob() can execute arbitrary code in userspace, fork_usermode_blob() can
>>> allow execution of e.g. statically linked HTTP server and statically linked DBMS server, without
>>> giving LSM modules a chance to understand the intent of individual file-less execve() request.
>>> If many different statically linked programs were executed via fork_usermode_blob(), how LSM
>>> modules can determine whether a syscall from a file-less process should be permitted/denied?
>> What you're saying is tomoyo doesn't trust kernel modules that are built-in
>> as part of vmlinux and doesn't trust vmlinux build.
>> I cannot really comprehend that since it means that tomoyo doesn't trust itself.

That's not a rational conclusion.

>>> By the way, TOMOYO LSM wants to know meaningful AT_SYMLINK_NOFOLLOW pathname and !AT_SYMLINK_NOFOLLOW
>>> pathname, and currently there is no API for allow obtaining both pathnames atomically. But that is a
>>> different problem, for what this mail thread is discussing would be whether we can avoid file-less
>>> execve() request (i.e. get rid of fork_usermode_blob()).
>> tomoyo does path name resolution as a string and using that for security?
>> I'm looking at tomoyo_realpath*() and tomoyo_pathcmp(). Ouch.
>> Path based security is anti pattern of security.
>> I didn't realize tomoyo so broken.

A lawyer would respond "asked and answered". This argument is
old. We had it in the 1980's with Unix systems. While you can't
identify a *object* using a path name, you can and must use a
path name to identify *user intentions*. If that were not the case
the audit system would be massively less sophisticated. Whether
path name based controls are valuable on a system with the
namespace characteristics of Linux (complete anarchy) is in the
eye of the beholder.

We have Linux Security Modules (LSM) because, as Linus put it,
"security people are insane" and incapable of agreeing on anything.
Security is inherently subjective. AppArmor make some people feel safe,
while others like SELinux. I understand that eBPF is now the cat's
pajamas. We don't go ripping out existing security just because
someone thinks poorly of it. Security features don't go in all that
often without some malice aforethought.



  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200607014935.vhd3scr4qmawq7no@ast-mbp>
     [not found] ` <33cf7a57-0afa-9bb9-f831-61cca6c19eba@i-love.sakura.ne.jp>
     [not found]   ` <20200608162306.iu35p4xoa2kcp3bu@ast-mbp.dhcp.thefacebook.com>
     [not found]     ` <af00d341-6046-e187-f5c8-5f57b40f017c@i-love.sakura.ne.jp>
     [not found]       ` <20200609012826.dssh2lbfr6tlhwwa@ast-mbp.dhcp.thefacebook.com>
     [not found]         ` <ddabab93-4660-3a46-8b05-89385e292b75@i-love.sakura.ne.jp>
     [not found]           ` <20200609223214.43db3orsyjczb2dd@ast-mbp.dhcp.thefacebook.com>
     [not found]             ` <6a8b284f-461e-11b5-9985-6dc70012f774@i-love.sakura.ne.jp>
     [not found]               ` <20200610000546.4hh4n53vaxc4hypi@ast-mbp.dhcp.thefacebook.com>
     [not found]                 ` <1be571d2-c517-d7a7-788e-3bcc07afa858@i-love.sakura.ne.jp>
     [not found]                   ` <20200610033256.xkv5a7l6vtb2jiox@ast-mbp.dhcp.thefacebook.com>
2020-06-10  7:30                     ` Tetsuo Handa
2020-06-10 16:24                       ` Casey Schaufler [this message]
     [not found] <87d066vd4y.fsf@x220.int.ebiederm.org>
     [not found] ` <20200611233134.5vofl53dj5wpwp5j@ast-mbp.dhcp.thefacebook.com>
     [not found]   ` <87bllngirv.fsf@x220.int.ebiederm.org>
     [not found]     ` <CAADnVQ+qNxFjTYBpYW9ZhStMh_oJBS5C_FsxSS=0Mzy=u54MSg@mail.gmail.com>
     [not found]       ` <CAADnVQLuGYX=LamARhrZcze1ej4ELj-y99fLzOCgz60XLPw_cQ@mail.gmail.com>
     [not found]         ` <87ftaxd7ky.fsf@x220.int.ebiederm.org>
     [not found]           ` <20200616015552.isi6j5x732okiky4@ast-mbp.dhcp.thefacebook.com>
     [not found]             ` <87h7v1pskt.fsf@x220.int.ebiederm.org>
     [not found]               ` <20200623183520.5e7fmlt3omwa2lof@ast-mbp.dhcp.thefacebook.com>
     [not found]                 ` <87h7v1mx4z.fsf@x220.int.ebiederm.org>
     [not found]                   ` <20200623194023.lzl34qt2wndhcehk@ast-mbp.dhcp.thefacebook.com>
     [not found]                     ` <b4a805e7-e009-dfdf-d011-be636ce5c4f5@i-love.sakura.ne.jp>
     [not found]                       ` <20200624040054.x5xzkuhiw67cywzl@ast-mbp.dhcp.thefacebook.com>
     [not found]                         ` <5254444e-465e-6dee-287b-bef58526b724@i-love.sakura.ne.jp>
     [not found]                           ` <20200624063940.ctzhf4nnh3cjyxqi@ast-mbp.dhcp.thefacebook.com>
2020-06-24  7:05                             ` Tetsuo Handa
2020-06-24 15:41                               ` Casey Schaufler
2020-06-24 17:54                                 ` Alexei Starovoitov
2020-06-24 19:48                                   ` Casey Schaufler
     [not found]                     ` <878sgck6g0.fsf@x220.int.ebiederm.org>
     [not found]                       ` <CAADnVQL8WrfV74v1ChvCKE=pQ_zo+A5EtEBB3CbD=P5ote8_MA@mail.gmail.com>
2020-06-24 23:14                         ` Tetsuo Handa
2020-06-25  1:35                           ` Alexei Starovoitov
2020-06-25  6:38                             ` Tetsuo Handa
2020-06-25  9:57                               ` Greg KH
2020-06-25 11:03                                 ` Tetsuo Handa
2020-06-25 12:07                                   ` Greg KH
2020-06-25 14:21                                     ` Tetsuo Handa
2020-06-25 19:34                                     ` David Miller
2020-06-26  1:36                                       ` Linus Torvalds
2020-06-26  1:51                                         ` Alexei Starovoitov
2020-06-26  4:58                                           ` Tetsuo Handa
2020-06-26  5:41                                             ` Alexei Starovoitov
2020-06-26  6:20                                               ` Tetsuo Handa
2020-06-26  6:39                                                 ` Alexei Starovoitov
2020-06-25 12:56                           ` Stephen Smalley
2020-06-25 13:25                             ` Greg Kroah-Hartman
2020-06-25 14:26                               ` Stephen Smalley
2020-06-25 14:36                                 ` Stephen Smalley
2020-06-25 15:21                                 ` Tetsuo Handa
2020-06-25 16:03                                   ` Stephen Smalley
2020-06-25 16:06                                   ` Casey Schaufler

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=ba722761-ae29-9f1d-b851-ee2b75e0bb91@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=GLin@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bmeneg@redhat.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yamada.masahiro@socionext.com \
    /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

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git