linux-kernel - Re: [DISCUSSION] proposed mctl() API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250529143132.b22099b8ce3452bbba25f813@linux-foundation.org>
Date: Thu, 29 May 2025 14:31:32 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, "Liam R . Howlett"
 <Liam.Howlett@...cle.com>, David Hildenbrand <david@...hat.com>, Vlastimil
 Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>, Arnd Bergmann
 <arnd@...db.de>, Christian Brauner <brauner@...nel.org>, SeongJae Park
 <sj@...nel.org>, Usama Arif <usamaarif642@...il.com>, Mike Rapoport
 <rppt@...nel.org>, Johannes Weiner <hannes@...xchg.org>, Barry Song
 <21cnbao@...il.com>, linux-mm@...ck.org, linux-arch@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-api@...r.kernel.org, Pedro Falcato
 <pfalcato@...e.de>
Subject: Re: [DISCUSSION] proposed mctl() API

On Thu, 29 May 2025 15:43:26 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:

>
> madvise()
>
> ...
>
> process_madvise()
>
> ...
>
> prctl()
>
> ...
>

Yeah.  I think there has always been an attitude "ooh, new syscalls are
scary and I probably need permission from someone so let's graft it
onto something which is already there and hope nobody notices".

New syscalls are super easy and are cheap - it's just a table entry! 
If it makes sense as a standalone thing, do that.

> The proposed interface is simply:
> 
> int mctl(int pidfd, int action, unsigned int flags);

Well, why `flags'?  One could even add a syscall per operation. 
Debatable.

> Of course, security will be of utmost concern (Jann's input is important
> here :)
> 
> We can vary security requirements depending on the action taken.
> 
> For an initial version I suggest we simply limit operations which:
> 
> - Operate on a remote process
> - Use the MCTL_SET_DEFAULT_EXEC flag
> 
> To those tasks which possess the CAP_SYS_ADMIN capability.
>
> This may be too restrictive - be good to get some feedback on this.

Permissions needs careful consideration on a case-by-case basis.
Clearly in many cases, user A should be able to manipulate user A's
mm's.

And if different modes of mctl() end up with different permission
structures, one wonders why everything was clumped under the same
syscall!  mctl() becomes "prctl() for memory".

Anyway, fun discussion.  I'm with willy ;)