linux-kernel - Re: IMA: How to manage user space signing policy with others

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]

Date:	Thu, 28 Feb 2013 15:57:35 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org
Subject: Re: IMA: How to manage user space signing policy with others

On Thu, Feb 28, 2013 at 03:30:01PM -0500, Mimi Zohar wrote:

[..]
> > So we need few more things from IMA for it to support the case of user
> > space signing.
> > 
> > - Ability to make sure kernel specified rules can not be overridden.
> 
> Our posts must have crossed -
> http://marc.info/?l=linux-security-module&m=136207944823661&w=2
> 
> > - Ability to not cache results so that direct writes to disk could
> >   be detected.
> 
> I'm not going to argue the futility of this argument.  I'll leave that
> to others more qualified.  If you really are concerned, then be my guest
> and define a general 'nocaching' option, not rule specific.  Replacing
> the policy won't affect the option.
> 
> > Till then I can't see how can I use IMA to implement process signing.
> 
> Vivek, you continue to imply that IMA doesn't cut it for your use case,
> yet ignore my suggestions.

Hi Mimi,

You asked me to not come up with new signing scheme and look into IMA
and make use of it. And that's what I am trying to do. As I continue
to do implementation, new concerns crop up and I am raising these.

I have not ignored any of your suggestions. This mail I sent before you
responded back with above mail where you seem to have suggested that
that disable "policy" interface based on kconfig option. I don't think
it was suggested in any of the mail threads before.

I have concerns w.r.t to disabling "policy" interface. This is like
choosing one feature over other. And I am concerned that somebody
will come back later that why did you disable "policy" interface and
broke my use case.

I would also like to understand that why "caching results" is not a
concern (or why argument is futile) w.r.t what I am trying to do. On
a system where whole of the user space is not signed, a root process
can go and directly write to disk and IMA will never detect it.

If remote attestation is happening, it probably is fine because no
known process is supposed to do that. And if unknown process runs, it
will be detected.

But without remote, attestation, to me it is a very valid concern
and is not addressed by current IMA implementation.

So no, I am not trying to ignore your suggestions. Just that there
are many concerns and I don't think all of my concerns have been
addressed yet.

Also if I define a separate "nocaching" option, again it will impact
the performance of other use cases IMA might have. You are saying
that choose one functionality over other and I think that probably
is not the best idea.

So to me, IMA should be beefed up to support all the use cases, instead
of hardcoding things using kconfig option and choose one functionality
over other.

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/