> 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 number of challenges
that prevent
us enabling enforcement on all SELinux domains unfortunately. While in the long
run that would be a preferred option, in the short run this doesn't
seem feasible. I
would assume the problem of enabling full SELInux enforcement would plague
any big project that didn't have them enabled from the get going.
--Daniil
On Wed, Aug 03 2022 at 12:29P -0400,
Daniil Lunev <[email protected]> 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 has permission to open?
> That would be the ideal solution, but there is a number of challenges
> that prevent
> us enabling enforcement on all SELinux domains unfortunately. While in the long
> run that would be a preferred option, in the short run this doesn't
> seem feasible. I
> would assume the problem of enabling full SELInux enforcement would plague
> any big project that didn't have them enabled from the get going.
> --Daniil
I'm not going to take this patch. It isn't the proper way to handle
preventing use of a DM device. In addition, the patch's header doesn't
speak to a proper review/audit of implications this change would have
on all aspects of a DM device's capabilities. If Chrome OS needs this
as a stop-gap then please carry it as needed.
Regards,
Mike
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 has permission to open?
> That would be the ideal solution, but there is a number of challenges
> that prevent
> us enabling enforcement on all SELinux domains unfortunately. While in the long
> run that would be a preferred option, in the short run this doesn't
> seem feasible. I
> would assume the problem of enabling full SELInux enforcement would plague
> any big project that didn't have them enabled from the get going.
> --Daniil
Have you also considered unlinking the device node (/dev/dm-$idx) from the
filesystem after it has been set up for swap?
- Eric
> 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'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
> on all aspects of a DM device's capabilities.
I would gladly clarify the commit message, and I am sorry
for making it terse in the beginning. Can you please
clarify, what capabilities are you concerned about? The
change shouldn't change any existing semantics if the
mechanism is never used on a specific system, and only
alters "open" behaviour in the cases where the specific
message was issued, but I am happy to cover any
additional aspects you are concerned about
Thanks,
Daniil
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 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.
- Eric
> 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 out, let me think on that