linux-kernel - Re: [link@...gy.org: Re: [patch 2/8] personality: fix PER_CLEAR_ON

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:	Sat, 18 Jul 2009 18:38:05 -0700
From:	Julien TINNES <jt@....org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>, Julien Tinnes <jt@....org>,
	Tavis Ormandy <taviso@....lonestar.org>,
	Christoph Hellwig <hch@...radead.org>,
	Kees Cook <kees@...ntu.com>, Eugene Teo <eugene@...hat.com>,
	Athanasius <link@...gy.org>
Subject: Re: [link@...gy.org: Re: [patch 2/8] personality: fix	PER_CLEAR_ON_SETID
 (CVE-2009-1895)]

Athanasius a écrit :
> On Sat, Jul 18, 2009 at 01:48:06PM -0700, Linus Torvalds wrote:
>> On Sat, 18 Jul 2009, Greg KH wrote:
>>> and you have the whole idea of personalities being some kind of security
>>> mechanism exposed as a joke.
>> It's _not_ a "security mechanism". It never was.
> ...
>> In the absense of raised capabilities, the personality flags don't matter: 
>> because they aren't security. If you have a personality flag that says "I 
>> want to mmap at virtual address zero", you're still going to be limited by 
>> the security layer, and if the security layer says "nope, you can't do 
>> that", then your personality doesn't matter.
>>
>> See?
> 
>   I can understand and appreciate that, yes.
> 
>   However the content of 'cat /proc/execdomains' is mis-leading for
> the default Execution Domain.  The string '0-0' implies either that you
> can only set 1 of 3 personalities whilst this Execution Domain is current
> OR that this Execution Domain will only be used whilst the set personality
> is one of those 3.  But neither is actually true as this default Execution
> Domain (being the only one in vanilla kernel tree) is a special case.
>   If you don't see a valid reason to change personality(2) behaviour (thus
> still allowing setting aribtrary personality values) then surely it would
> make more sense for the default domain to set pers_high to PER_MASK ?
> I'd suggest it actually be 0xffffffff but the field is only a char.
> 

So I think we all agree that this is not a security boundary and that
there is no security problem here.
A process should be able to change it's own personality, there is no
issue with this as long as we restrict the set of personalities which
are preserved when the process gets new privileges.

Currently, all the personalities are being implemented inside one
execution domain, the default one.

To address your concerns:
- pers_low and pers_high are compared to the *base* personality (without
flags), so it's correct to define them as uchar. pers should perhaps be
defined as uchar as well in lookup_exec_domain
- since all personalities are implemented inside the default execution
domain, it would indeed make sense to set default_exec_domain.pers_high
to PER_MASK. It would not change anything in practice, but it would make
sense.

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