> There is no such thing as WRITE UNAVAILABLE in NVMe.
Apologize, that is WRITE UNCORRECTABLE. Chapter 3.2.7 of
NVM Express NVM Command Set Specification 1.0b
> That being siad you still haven't actually explained what problem
> you're even trying to solve.
The specific problem is the following:
> So bloody punich the vendors for it. Unlike most of the Linux community
> your actually have purchasing power and you'd help everyone by making
> use of that instead adding hacks to upstream.
Hi Cristoph,
I just want to note that the primitive this patchset introduces would not
map
to WRITE
> I thought you were trying to defend against path traversal attacks, not
> arbitrary code execution? If your threat model includes arbitrary code
> execution by root, you really need to be using SELinux.
Hm, this is actually a very good point which we somehow missed, hm.
Thanks for pointing that
> I'm not going to take this patch. It isn't the proper way to handle
> preventing use of a DM device.
Can you suggest a better mechanism that would be acceptable
from your perspective?
> In addition, the patch's header doesn't speak to a proper
> review/audit of implications this change would
> Have you also considered unlinking the device node (/dev/dm-$idx) from the
> filesystem after it has been set up for swap?
Yes, the node can be re-linked with mknod, thus is not a suitable solution.
--
dm-devel mailing list
dm-devel@redhat.com
> This seems like an access control policy, which the Linux kernel already has a
> lot of mechanisms for. Chrome OS already uses SELinux. Couldn't this be
> solved
> by giving the device node an SELinux label that no one has permission to open?
That would be the ideal solution, but there is a
Hello all
To signal boost here. What can we do to advance the discussion on this
topic? Can we move forward with the approach or are there any
alternative suggestions how the desired behaviour can be achieved?
Thanks,
--Daniil
On Tue, Jul 19, 2022 at 9:42 AM Daniil Lunev wrote:
>
> We unde
On Wed, Jul 20, 2022 at 11:49:07PM -0700, Eric Biggers wrote:
> I'm glad to see a proposal in this area -- this is something that is greatly
> needed. Chrome OS is looking for something like "dm-crypt with inline crypto
> support", which this should work for. Android is also looking for
We understand that if someone acquires root it is a game over. The intent of
this mechanism is to reduce the attack surface. The exposure might be a
certain system daemon that is exploited into accessing a wrong node in
the filesystem. And exposing modifiable system memory is a pathway for
further
necessary
configuration has been done to the device at boot time.
--Daniil
On Fri, Jul 15, 2022 at 6:13 AM Mike Snitzer wrote:
>
> On Sun, Jul 03 2022 at 8:02P -0400,
> Daniil Lunev wrote:
>
> > A message can be passed to device mapper to prohibit open on a certain
> > m
A message can be passed to device mapper to prohibit open on a certain
mapped device. This makes possible to disallow userspace access to
raw swapped data if the system uses device mapper to encrypt it at rest.
Signed-off-by: Daniil Lunev
---
drivers/md/dm-core.h | 1 +
drivers/md/dm
(e.g. deffer remove), this one
allows an explicit signal via message interface to signalize device
mapper shall block any further access to the device. The primary use
case is to restrict userspace access to decrypted data after a device
was setup with a kernel facility (e.g. swap).
Daniil Lunev (1
12 matches
Mail list logo
