On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
> On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> >So I implemented a rather quick hack that introduces a new mmap()
> >flag MAP_NOZERO (only valid for anonymous mappings) and the vma
> >counter-part VM_NOZERO. Also, a new sys_brk2() has been introduced
> >to accept a new flags parameter. A brief description of the
> >patches follows in the next emails.
>
> Hmm, sounds like this would also need a "MAP_NOREUSE" flag of some
> kind for security sensitive applications. Basically, I wouldn't want
> my ssh-agent pages holding private SSH keys to be reused by my web
> browser which then gets exploited :-D.
PGP at least (and I think GPG still) did overwrite keys before calling
free(), and attempted to use mlock(). Looks like ssh-agent doesn't use
mlock -- at least it hasn't in this case:
% grep Lck /proc/`pidof ssh-agent`/status
VmLck: 0 kB
% ulimit -a | grep lock
file size (blocks) unlimited
core file size (blocks) 0
locked-in-memory size (kb) 32
file locks unlimited
Requiring security-sensitive apps to use a new flag to get safe behavior
is dangerous. Better to be safe by default and turn on the
less-safe-but-faster behavior for the cases that benefit from it.
> It would also be a massive
> information leak under SELinux. To fix it properly according to the
> SELinux model you would need to tag each page with a label
> immediately after it's freed and then do an access-vector-check
> against the old page and the new process before allowing reuse. On
> the other hand, that would probably be at least as expensive as
> zeroing the page.
I still think that using uid in mm_struct is wrong, and some kind of
abstraction is required. I called this "free pool" in
<[email protected]>, but I think that name is
misleading -- I am not proposing that this should be part of the
management of free pages, but should be a label which abstracts "safe to
share freed pages among" groups. Then different SELinux protection
domains would simply have different labels.
-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
