linux-kernel - Re: [PATCH] exitz syscall

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]

Date:   Sun, 12 Nov 2023 10:44:24 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Jasper Niebuhr <yjnworkstation@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Willy Tarreau <w@....eu>, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] exitz syscall

On Sun, Nov 12, 2023 at 11:03:43AM +0100, Jasper Niebuhr wrote:
> 
> Do you think it could make sense to enable zeroing on exit only for
> ranges of memory (base + len) with a config dictating the max amount
> of bytes (or pages or whatever) that a single process is allowed to
> flag for zeroing? This way the DoS issue is effectively solved and the
> config could always be set to 0 (by default I guess), which would
> effectively leave any common system unchanged. The users that actually
> want to use this feature could then decide on their own how much it is
> worth to them and how big of a task they want the kernel to perform at
> max on exit.

How about adding a flag MLOCK_ZERO_ON_FREE used by the mlock2() system
call?  The number of pages which an unprivileged process can lock is
already capped via RLIMIT_MEMLOCK (or else mlock would be it own
denial of service attack).  That way if process dies from crash, the
keys would be zero'ed.

The argument against this is that this functionality could be an
attractive nuisance, since best practice is to zero any keying
information the moment you no longer need it, instead of depending on
magic OS behavior to take care of something that you darned well
should be doing yourself.  I understand that in your case, you're
trying to protect a key manager, whose *job* it is to hold onto keys
for long periods of time.  So this advice might not be as applicable
in your case.

I do suspect that the chances that trying to grab a memory page after
it has been released is one of the least likely way keys would be
exfiltrated.  I'd be much more worried about stack/buffer overflow
attacks in any of the libraries used by the key manager, for example.
Or zero-day attacks on the kernel which then grab the keys from the
key manager process while it is still running....

Cheers,

					- Ted