[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <21B1982A-2C53-4E5B-BB7E-178EAAADB089@juniper.net>
Date: Wed, 1 Dec 2021 18:40:59 +0000
From: Travis Finkenauer <tmfink@...iper.net>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: IMA gadgets
> On Dec 1, 2021, at 12:06 AM, Johannes Segitz <jsegitz@...e.de> 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.
-Travis
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.
