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: <1360856928.3524.626.camel@falcor1.watson.ibm.com>
Date:	Thu, 14 Feb 2013 10:48:48 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.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 Thu, 2013-02-14 at 09:40 -0500, Vivek Goyal wrote:
> On Wed, Feb 13, 2013 at 04:45:23PM -0500, Mimi Zohar wrote:
> 
[..]

> > > 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).

I think we're back to my original comment that the bprm_check hook might
need to be moved or an additional hook added, as the existing bprm_check
hook is located before the file is locked from modification.  :)

thanks,

Mimi



--
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/