Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757605AbeAIBtd (ORCPT + 1 other); Mon, 8 Jan 2018 20:49:33 -0500 Received: from 122.185.24.109.rev.sfr.net ([109.24.185.122]:46602 "EHLO mx.synack.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755879AbeAIBtb (ORCPT ); Mon, 8 Jan 2018 20:49:31 -0500 X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Mon, 08 Jan 2018 20:49:30 EST From: Samir Bellabes To: Alan Cox Cc: Thomas Gleixner , Jon Masters , "Woodhouse\, David" , Paolo Bonzini , Linus Torvalds , Andi Kleen , Greg Kroah-Hartman , Tim Chen , Linux Kernel Mailing List , Dave Hansen , Jeff Law , Nick Clifton , Willy Tarreau Subject: Re: Avoid speculative indirect calls in kernel References: <20180103230934.15788-1-andi@firstfloor.org> <20180104015920.1ad7b9d3@alans-desktop> <1515054014.12987.75.camel@amazon.co.uk> <403e65be-cfd1-fd08-0401-2e26470b63d4@redhat.com> <4dde456c-fd15-e768-8876-5844c8b7c455@redhat.com> <20180105121241.497742f7@alans-desktop> Date: Tue, 09 Jan 2018 02:44:13 +0100 In-Reply-To: <20180105121241.497742f7@alans-desktop> (Alan Cox's message of "Fri, 5 Jan 2018 12:12:41 +0000") Message-ID: <87d12jkdqq.fsf@synack.fr> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Alan Cox writes: > On Fri, 5 Jan 2018 01:54:13 +0100 (CET) > Thomas Gleixner wrote: > >> On Thu, 4 Jan 2018, Jon Masters wrote: >> > P.S. I've an internal document where I've been tracking "nice to haves" >> > for later, and one of them is whether it makes sense to tag binaries as >> > "trusted" (e.g. extended attribute, label, whatever). It was something I >> > wanted to bring up at some point as potentially worth considering. >> >> Scratch that. There is no such thing as a trusted binary. > > There is if you are using signing and the like. I'm sure SELiux and > friends will grow the ability to set per process policy but that's > certainly not a priority. There was a proposed security module providing such a per-process policy. When a process want to execute a specific networking syscall regarding specific "transport protocol", the security module catches the syscall at the LSM hook, and ask user about the "verdict" (authorized or not ?) Verdicts are put inside "tickets" (it's a struct of information regarding the autorization). Verdicts can have timeout or live forever. They are managed by a hashtable. The policy can be define by attaching tickets to process with a userspace tool. Interface between userspace command tool and kernel is using netlink protocol. I managed to do the same on process and memory. memory access requires process to delivery a available ticket. Sharing memory is like "process A has a ticket required to access memory of process B" Of course, direct assignation, throught asm code or operation like : buffer[x] = y; are impossible to catch at this level. It requires hooks at the asm level. As I understand, Willy needs to built such a took to classify "trusted" binaries from others. This is just the top of the iceberg, because, after starting to mark process as "trusted" or not, there is a need of an architecture to track such operations, evaluate incoherences, evaluate the convergence of such classification, regarding thousands of binaries, in a lot of contexts. This was the big part of the job. last series I propose was years ago under the name : [RFC,v3,00/10] snet: Security for NETwork syscalls and particulary : [RFC,v3,08/10] snet: introduce snet_ticket http://patchwork.ozlabs.org/patch/93808/ thanks; sam