Messages in this thread | | | From | Samir Bellabes <> | Subject | Re: Avoid speculative indirect calls in kernel | Date | Tue, 09 Jan 2018 02:44:13 +0100 |
| |
Alan Cox <gnomes@lxorguk.ukuu.org.uk> writes:
> On Fri, 5 Jan 2018 01:54:13 +0100 (CET) > Thomas Gleixner <tglx@linutronix.de> 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
| |