linux-kernel - Re: [PATCH 2/2] ima: Support appraise_type=imasig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130214144033.GA13047@redhat.com>
Date:	Thu, 14 Feb 2013 09:40:34 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional

On Wed, Feb 13, 2013 at 04:45:23PM -0500, Mimi Zohar wrote:

[..]
> Option 3: appraise_type:= [imasig] | [imahash] | [optional]
> 
> Dmitry is recommending this syntax, as IMA_DIGSIG will be set in the
> iint flags.

I like option 3. If there is a use case down the line where definition
of optional needs to be refined in such a way that we want to force
signature or hash then we can extend appraise_type to also include
following.

Option 3: appraise_type:= [imasig] | [imahash] | [optional] |
				[imasig_optional] | [imahash_optional]

> 
> 
> Any of these options should work.
> 
> > If it would happen that it contains signature, then IMA_DIGSIG flag
> > would be set,
> > and process could get needed capability as Vivek wants.
> 
> With the 'optional' condition, both unsigned and validly signed files
> will succeed.  One way of making this information accessible to an LSM,
> would be to define a new integrity capability and set it here.  The new
> integrity capability would indicate the file was validly signed. 

Thinking loud.

The problem with integrity capability is that it goes only so far. If
we provide capability in exec() path, then that capability means much
more in the sense, we know file is locked to run from memory. An integrity
capability just means file is validly signed.

So exec() code might have to do another capability on top which will
also ensure that file is executable is locked in memory and signature
verification is done after loading in memory so that it is not open
to writing to disk block attacks.

And based on this capability we probably need to deny write access to file
till file is open for exec() (I noticed that after load, we seem to be
allowing access to write access).

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/