[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706271642340.3879@alien.or.mcafeemobile.com>
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