Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux