Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 1 Dec 2021 18:40:59 +0000
From: Travis Finkenauer <>
To: "" <>
Subject: Re: IMA gadgets

> On Dec 1, 2021, at 12:06 AM, Johannes Segitz <> wrote:
> From a security POV it doesn't
> help much (on a normal Linux system, can be different if you really strip
> it down).

I agree. It's difficult to add an IMA-like security policy that is both effective and general-purpose. But, if you don't care about your system being general-purpose, IMA can be useful on "locked-down vendor systems".

If you can use IMA to enforce a "write XOR execute" policy on a filesystem, then you could have separate filesystems for executable code and writeable config. For example, you could:

1) Have your executable code in a read-only squashfs filesystem. Use IMA to enforce only signed binaries will run.
2) Put writeable data in a "noexec" filesystem.
3) Lock-down (or remove) interpreters (python, perl, bash, etc.) that could "execute" data whose provenance does not come from a signed, read-only filesystem.

Such a locked-down setup provides some security by trying to ensure only vendor-provided code is executed.
But, this setup is probably not suitable for a general-purpose end-user system.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.