linux-kernel - Re: Upstream first policy

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: <a36005b51003081412u536c34cbu46b5288e32c73397@mail.gmail.com>
Date:	Mon, 8 Mar 2010 14:12:05 -0800
From:	Ulrich Drepper <drepper@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	Kyle McMartin <kyle@...artin.ca>,
	Alexander Viro <viro@....linux.org.uk>
Subject: Re: Upstream first policy

On Mon, Mar 8, 2010 at 10:08, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> Notice how it's really fundamentally about the pathname? When you create a
> new file and overwrite /etc/passwd with that file, the security rules
> really do _not_ come from your newly created inode, they come from the
> fact that you made the path "/etc/passwd" point to that inode.

This is not a fundamental problem.  It's rather a detail of the
current policies and legacy apps.

I think I would like to see /etc/passwd to also get a file type like
/etc/shadow.  This is I think today not done because of the work
involved and the perceived lower severity because passwords are in
/etc/shadow.

So let's talk about /etc/shadow.  If somehow the file is removed and
somebody creates a new file that file won't automatically get the
right label.  This means that code reading the file then could be
prevented from doing this with appropriate policy rules.  Here the
filename is not sufficient for access.  You also need the label and
that you won't get without subverting the system.  With filename based
mechanisms this isn't the case: once the file is compromised the
attack succeeded.

Yes, the current situation isn't optimal.  We have to make the
policies more complicated and we have to get rid of restorecond (at
least for most cases).  But there is no fundamental problem with
labels while filename-based mechanisms provide no security
improvement.
--
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/