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:	Wed, 27 Jun 2007 17:17:54 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nicholas Miell <nmiell@...cast.net>
cc:	Hugh Dickins <hugh@...itas.com>,
	Ulrich Drepper <drepper@...il.com>, blaisorblade@...oo.it,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/3] MAP_NOZERO - implement sys_brk2()

On Wed, 27 Jun 2007, Nicholas Miell wrote:

> 1) euid is not sufficient, you need to store away arbitrary LSM
> information and call LSM hooks to decide security equivalence. The same
> applies to VServer or whatever other container system you use.

The EUID that is used now, can easily be any cookie. It can be an LSM 
cookie (if LSM is active in the system). We don't do complex checks, like 
group permission & Co.  We assume that if a UID-cookie had such data 
available (or it generated it), it can have it back uncleared.



> 2) Two processes, A and B, are in separate VFS namespaces but have
> equivalent security identity according to LSM. Process A reads data from
> file F which is not visible in process's B's namespace. You have to
> prevent process B from ever getting a page that once contained data from
> file F.

They have the *same* security identity. It means that at any time such 
security identity can access resources on both VFS (if it is allowed to 
access such resources - according to security rules in place, LSM or not).
Data is either generated by the security identity, or it is faulted in 
(and it means that the security identity had the GO from the security 
provisioning to access such resource).



> 3) mlock() is often used by programs like GPG to prevent decrypted
> secret keys from ever getting swapped out. You need to zero all
> once-mlocked pages before they get reused to prevent that page from
> getting swapped to disk or application bugs from leaking the key.

GPG and other security software do also memclear on top of mlock, to 
prevent such memory staying alive at all. Just for example, you don't want 
in any case that after an munlock you app core and data goes down.



- Davide


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ