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]

Message-ID: <20090719193917.GK6722@miggy.org>
Date:	Sun, 19 Jul 2009 20:39:17 +0100
From:	Athanasius <link@...gy.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	Athanasius <link@...gy.org>, Julien TINNES <jt@....org>,
	Greg KH <gregkh@...e.de>,
	Tavis Ormandy <taviso@....lonestar.org>,
	Christoph Hellwig <hch@...radead.org>,
	Kees Cook <kees@...ntu.com>, Eugene Teo <eugene@...hat.com>
Subject: Re: [link@...gy.org: Re: [patch 2/8] personality: fix
	PER_CLEAR_ON_SETID (CVE-2009-1895)]

On Sun, Jul 19, 2009 at 12:27:05PM -0700, Linus Torvalds wrote:
> On Sun, 19 Jul 2009, Athanasius wrote:
> > 
> >   And it's that "as long as we ..." that still bothers me.  I've *never*
> > had any need for any use of this personality feature and this net/tun.c
> > exploit has proven there can be security gotchas with it.
> 
> I do agree. Some of those features may not be worth the cost.
> 
...
> 
> So I do agree that we can probably get rid of some really dated 
> personality bits. But I don't think we can really get rid of the concept. 
> Because compatibility is always of paramount importance.

  Would you agree that having these features default-off would be best?
That way a user or sysadmin isn't suddenly surprised by different
behaviour.  And those users who do need the functionality can turn it
on.  Whether that be via compile-time option or a sysctl I leave up to
the people who know more about Linux Kernel coding than I.  However, I'd
guess in the interests of vendor-kernel flexibility it should tend
towards the latter.
  And, of course, this is what I *thought* Execution Domains were for
when looking at the code.  Have only the default one and you're limited
pretty much to 'vanilla Linux'.  Actually have available a module for
another personality and you allow its selection by users.

  Put the choice in the hands of all users (read sysadmins even if its
their personal machine) rather than only in the hands of those who can
be bothered to recompile the kernel with an option, and currently
needing to hand-edit the source themselves to change the behaviour.

-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
--
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/