> 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
On Thu, Aug 04, 2022 at 06:44:53AM +1000, Daniil Lunev wrote:
> > 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.
I thought you were trying to
> 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
On Wed, Aug 03, 2022 at 02:29:40PM +1000, Daniil Lunev wrote:
> > 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
On Wed, Aug 03 2022 at 12:29P -0400,
Daniil Lunev wrote:
> > 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
On Wed, Aug 03, 2022 at 02:12:26PM +1000, Daniil Lunev wrote:
> 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,
>
> 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 understand
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
Dne 15. 07. 22 v 11:36 Mikulas Patocka napsal(a):
On Fri, 15 Jul 2022, Daniil Lunev wrote:
Hi Mike,
Thank you for your response. I should have probably added more context
to the commit message that I specified in the cover letter. The idea is to
prohibit access of all userspace, including the
On Fri, 15 Jul 2022, Daniil Lunev wrote:
> Hi Mike,
> Thank you for your response. I should have probably added more context
> to the commit message that I specified in the cover letter. The idea is to
> prohibit access of all userspace, including the root. The main concern here
> is potential
Hi Mike,
Thank you for your response. I should have probably added more context
to the commit message that I specified in the cover letter. The idea is to
prohibit access of all userspace, including the root. The main concern here
is potential system applications' vulnerabilities that can trick
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
> 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:
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 +
15 matches
Mail list logo
