From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 6 Jun 2022 15:53:59 +0300 From: "Vladimir D. Seleznev" To: ALT Linux kernel packages development Message-ID: References: <20220602003100.524482-1-vt@altlinux.org> <20220602163914.GB11775@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2022 12:54:00 -0000 Archived-At: List-Archive: List-Post: On Mon, Jun 06, 2022 at 01:20:40PM +0400, Alexey Sheplyakov wrote: > Hi, > > On Sun, Jun 05, 2022 at 04:04:56PM +0300, Vladimir D. Seleznev wrote: > > > People who actually need security > > > > > > 1) don't use out-of-order CPUs (to avoid Meltdown, Spectre, etc) > > > 2) don't use Linux (so the kernel can be actually audited) > > > 3) don't exist > > > > I don't get the point of these. If we don't need security why should we > > bother with user/group processes/filesystems separation and permissions, > > chrooting, etc. We have a superuser, lets everything run with it! > > 1. In a way we already do (on desktop systems). All applications run with > the same uid and have the same permissions. Nothing prevents firefox > from sending my private GPG key to $BIG_BROTHER, or removing all files > (in $HOME), etc. I run firefox instanses and every semi-trusted applications with different uids, so none of them can still my GPG or any other secrets or corrupt my $HOME (until really bad things happen): $ ps -eo uid,comm |grep firefox |uniq 1022 firefox 1032 firefox 1020 firefox 1036 firefox > 2. If you keep restricting the basic system functionality (profiling, > namespaces, etc) to root only eventually people will be forced > to run everything as root to get a usable system. > > > 1) There are some tricks to significantly reducing impact of > > Spectre-like vulnerabilities, like disabling HT, separate processes to > > run on different trust-level CPU core, KPTI, etc. > > > 2) The kernel constantly reviewed, sure it is not an audit but some part > > are well reviewed, especially in general parts. > > I'll just leave this here: https://lkml.org/lkml/2021/4/21/454 I read this. This just prove that these were not detected at submission time, but in the end these were elicited. > > I think it is worth reducing the attack surface. > > There are a vast number of (privilege escalation) attacks which make > use of symlinks. Let's disable symlinks (for ordinary users). Some are mitigating with fs.protected_symlinks. But race conditions with symlinks are about attacking userspace privilleged processes, not the kernel. > And provide a magic knob (without any documentation) to re-enable them. Sure it should be documented. > > There were known vulnerabilities in the perf kernel subsystem that > > allowed to escalate privileges, > > There were known vulnerabilities in all kernel subsystem. Including > core ones, like mm (proofs: [1], [2], [3]). What about disabling CoW, > vmsplice, and other "insecure" stuff? Does it mean that we do not need to reduce attack surface because there were (and will) vulnerabilities in the core subsystem? > [1] https://lwn.net/Articles/849638 > [2] https://lwn.net/Articles/704231 > [3] https://lwn.net/Articles/268783 > > > and profiling is not a common task. > > Incorrect. Just because you don't care doesn't mean it's "not common". > > > I don't see why switching the knob is a big problem. > > The knob itself is not a big deal. The problem is the default value, > which prevents ordinary users from profiling their processes. Who is an ordinary user in your user model? What kind of users exist? I distinguish several types of users (the list is not intended to be exhaustive): 1. A homemaker or non-tech user that just uses a computer for reading/writing documents, listening music, watch videos and browsing. This kind of user does not need profiling. 2. A tech person who own personal computer, and this exactly person admins her/his device. If he/her need profiling, he/her can easily enable this feature. 3. A sysadmin who serves a lot of production servers. I think this type is most targeted for this feature. Same as 2. 4. An ordinary user of big cluster, who can be a developer for such system and who may need profiling. In that case he or her can ask the cluster sysadmin to enable this feature. -- WBR, Vladimir D. Seleznev