On Wed, Apr 3, 2019 at 2:59 AM Igor Zhbanov <i.zhbanov@xxxxxxxxxxxx> wrote:
>
> On 03.04.2019 1:31, Matthew Garrett wrote:
> > Remember that many interpreted languages allow execution of code
> > provided to them on the command line (eg, python -c) and also grant
> > access to arbitrary syscalls, so there's still no guarantee that
> > you're only executing trusted code.
>
> Yes. But in some installations you can get rid of interpreters at all or limit
> the number of scripts they can open. For example you can require that all
> scripts have to be signed.
No, that's my point - if you're able to pass code directly to the
interpreter then you're not protected by file signatures. python -c
'print("hello")' will execute without the user-provided code touching
IMA.
> And having this feature as a per-process you could still limit the attack
> surface by restricting e.g. network services as they are constantly attacked.
>
> So are you saying that this feature doesn't worth to make it?
I'm saying that before adding more security code you should describe
the attack that you're actually trying to prevent. What you're doing
prevents applications from opening a file read-only and then
mprotect()ing it to being executable without IMA noticing, but what
attack are you actually protecting against as a result? You block one
avenue of obtaining code execution that isn't measured by IMA, but
there are many more. Most (but not all) are blocked by requiring that
all files be signed, but if all files are signed we don't need to
change the behaviour here - opening the file read-only will be enough
to trigger an appraisal.
