linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lev R. Oshvang ." <levonshe@gmail.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>, Mimi Zohar <zohar@us.ibm.com>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: Re: [PATCH] integrity ima_policy : Select files by suffix
Date: Mon, 30 Mar 2020 23:01:10 +0300	[thread overview]
Message-ID: <CAP22eLEx4-06iTC5kw-GHoD=YVmLdLpN_JCCGx8PRMy4honiQg@mail.gmail.com> (raw)
In-Reply-To: <1585591534.5188.435.camel@linux.ibm.com>

On Mon, Mar 30, 2020 at 9:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> [The normal conventions for this mailing list is bottom post.]
>
> Lev,
>
> On Mon, 2020-03-30 at 20:21 +0300, Lev R. Oshvang . wrote:
> > I already answered to Mimi Zohar that applications expect file name in
> > open() syscall.
>
> And I disagreed with you.  Not only can filenames be renamed, as I
> mentioned, but they aren't protected, as Roberto said.
>
I politely remind you that the goal of IMA  is to provide the
application the guarantee that the file was not altered when it tries
to use it, whether it is open(), stat(), , execve , etc
BPRM_CHECK, MMAP_CHECK narrows the scope of checks to executable files/libs.

But there are a tons of files in file systems and we can not check them all.
My intention is to put under scrutiny just important configuration
files, systemd service files, some files in etc, ex /etc/shadow.

The result will be good for providing TCB, because we can be sure that
all systemd services passed attestation.
Right now we measure  sshd binary but we do not mesure sshd config.

An attacker may change the configuration file of iptables, sshd.
sudoers to make attack successful or leave a backdoor.
He can not achieve the attack goal if he changes a file name. The
application/service will just not start.
TOCTOU is not relevant. Attacker works from userspace but open()/IMA
happens in the kernel. So there is no way to avoid IMA check.

> > So there is no need to protect file name otherwise applications just
> > stop to work.
> > Even now when ima hash is not correct application stops to work.
> > Put aside scripts for a second. A lot of programs are configured in
> > .ini or .conf files.
> > The suffix is a very convenient way to provide these files would be measured.
> >
> > Now I returning to scripts.
> > It is very hard to enforce IMA checks in interpreters. And thinks
> > about perl scrips. awk. python scripts. etc
> > The proposed suffix rule is easy and lightweight.
> > I once had programmed BRM hook of LSM
> > I had a very hard time trying to figure out whether shell is opening a
> > script or data , how to get filename to check its signature.
> > Sometimes script file does not have shebang or does not have
> > executable permission.
>
> Only the interpreter knows how the file will be used.
>
Not true. It is a common practice to use file suffix to indicate how a
file is going to be used
Coding styles required from programmers to use suffixes.
So let's be on a common-sense side and agree that if some system as a
coding style use .sh for shell scripts name
we can use it in IMA policy rule.
> >
> > I hope I convinced you.
>
> There have been a number of attempts to define IMA policy rules based
> on pathname, which have not been upstreamed.  Feel free to use your
> solution, but it can't be upstreamed as is.
>
> Mimi
>
Hi Mimi,
I am completely newbie in such discussion so please forgive that I may
violate style again because I responded in the middle of your reply
Another argument that is responsible sysadmin may use the immutable
attribute to prevent name change,

Regards,
Lev

      reply	other threads:[~2020-03-30 20:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 12:27 [PATCH] integrity ima_policy : Select files by suffix Lev Olshvang
2020-03-30 16:45 ` Roberto Sassu
2020-03-30 17:21   ` Lev R. Oshvang .
2020-03-30 18:05     ` Mimi Zohar
2020-03-30 20:01       ` Lev R. Oshvang . [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP22eLEx4-06iTC5kw-GHoD=YVmLdLpN_JCCGx8PRMy4honiQg@mail.gmail.com' \
    --to=levonshe@gmail.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=zohar@linux.ibm.com \
    --cc=zohar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).