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
| ||
|
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/
Powered by blists - more mailing lists