linux-kernel - Re: mprotect abuse in slim

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 for Android: free password hash cracker in your pocket

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

Message-ID: <OFDF1FF03C.DB6D539B-ON85257261.006E437F-85257261.006F74D1@us.ibm.com>
Date:	Fri, 12 Jan 2007 15:08:32 -0500
From:	Mimi Zohar <zohar@...ibm.com>
To:	Pavel Machek <pavel@...e.cz>
Cc:	akpm@...l.org, Christoph Hellwig <hch@...radead.org>,
	kjhall@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	safford@...son.ibm.com
Subject: Re: mprotect abuse in slim

Pavel Machek <pavel@...e.cz> wrote on 01/11/2007 09:35:37 AM:

> Hi!
> 
> > SLIM implements dynamic process labels, so when a process
> > is demoted, we must be able to revoke write access to some
> > resources to which it has previously valid handles.
> > For example, if a shell reads an untrusted file, the
> > shell is demoted, and write access to more trusted files
> > revoked. Based on previous comments on lkml, we understand
> > that this is not really possible in general, so SLIM only
> > attempts to revoke access in certain simple cases.
> 
> Are you saying that SLIM is useless by design because interested
> parties can work around it?
>                      Pavel

Sorry that we were unclear about what happens in the case revocation
is not possible.  In those cases, the unsafe requested read or exec
that would normally trigger the demotion/revocation is denied, so
there is no way around the integrity model.

The goal of the low water mark integrity model is to be as transparent
as possible to the user. If the user asks for something to be done, we
allow it as much as possible, demoting the process as needed for
security.  If there is something that would need to be revoked, which
can't safely be revoked, then we deny the read/exec request, which is
secure, but possibly visible/annoying to the user. Fortunately in our
testing, there are only a few cases where this happens, and the
overall result is a model which is still much more transparent than
other models which don't allow demotion at all.

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