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]
Message-ID: <8bd0f97a0911171524r35783fa3o393c9584cc8f6634@mail.gmail.com>
Date:	Tue, 17 Nov 2009 18:24:43 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Eric Paris <eparis@...hat.com>,
	David Howells <dhowells@...hat.com>, graff.yang@...il.com,
	linux-kernel@...r.kernel.org, gyang@...ckfin.uclinux.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	Graff Yang <graf.yang@...log.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] mm/nommu.c: Fix improperly call of security API in mmap

On Tue, Nov 17, 2009 at 17:13, Andrew Morton wrote:
> On Fri, 16 Oct 2009 11:55:29 -0400 Eric Paris wrote:
>> On Fri, 2009-10-16 at 16:43 +0100, David Howells wrote:
>> > Eric Paris <eparis@...hat.com> wrote:
>> > > That would still call cap_file_mmap() and wouldn't solve your problem.
>> >
>> > Hmmm...  I guess I don't see the problem occur because I always run the
>> > programs as root.
>>
>> most likely yes, your processes are going to have CAP_SYS_RAWIO and will
>> happily sail through the cap_file_mmap().
>>
>> > I would guess that cap_file_mmap() and selinux_file_mmap() are, perhaps, too
>> > strict.  The hint shouldn't be rejected unless MAP_FIXED is also set, surely,
>> > but should rather be revised upwards.
>>
>> On the mmu side we don't check until the kernel has turned the hint into
>> a real address.  Which is apparently different then where the hook was
>> originally placed in the nommu side.
>>
>> > Certainly, addr==NULL and !MAP_FIXED is a reasonable case to permit, even in
>> > tightly secured MMU and SELinux mode...  After all, the manual page says:
>> >
>> >     If addr is NULL, then the kernel chooses the address at which to create
>> >     the mapping; this is the most portable method of creating  a  new  map-
>> >     ping.
>>
>> I agree, I think the choices are
>>
>> A) agree that we just shouldn't check the address on nommu
>>    A1) change kconfig to not allow the setting of these
>>       (easy to do for the LSM check, but not easy as it stands today
>>        for the cap_file_mmap() check)
>>    A2) change the addr_only to be a flags which indicate not to check
>>       (my original suggestion)
>>    A3) push the config_nommu down into the security code
>>       (your patch)
>> B) actually check the address, which requires moving the hook to a
>> location where it has been resolved.
>>       (graff yang's patch)
>>
>> I'll leave it up to you to determine which you like the best since you
>> know the implications of nommu.
>
> So what's the status of this issue now?  Should I merge the below into
> 2.6.32?

i think the patch as posted is the way to go, at least for now, and
should be merged.  it certainly works for us under Blackfin going by
Graff's tests.  but obviously this is ultimately David's call.
-mike
--
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