[d-kernel] [PATCH] UBUNTU: SAUCE: security, perf: Allow further restriction of perf_event_open

[Vladimir D. Seleznev]

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