linux-kernel - Re: [PATCH 6/7] Add /sys/kernel/notes

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:	Wed, 11 Jul 2007 15:04:23 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] Add /sys/kernel/notes

> Yeah, we've made that mistake before, and I'm not saying we are perfect 
> here, but if we make this world-readable, I think it needs to guarantee it 
> doesn't really give any rootkit people any new information.

It will give them at least as reliable an identification of the kernel
binary as the "uname -rv" info if they have access to a set of candidate
known binaries to select from.  It's of no direct help at all in getting
anything like kernel addresses.  In practice, it is probably no easier for
a rootkit to use than "uname -rv" to pick an exploit for a particular known
distro kernel binary, just easier for legitimate debugging tools.  I think
it's not only more harmless than what you might call "past mistakes", but
is actually just plain harmless.  But I'm not really one to talk a man out
of his paranoia.

> And yes, I do think normal people shouldn't be able to read the vmlinuz 
> binary, the same way they are generally not allowed to read /etc/grub.conf 
> etc.

I have no special opinions about that, but I haven't seen an install where
the /boot files were not readable anyway.  But certainly in a chroot or
such, you won't have /boot at all but might have /proc and /sys.

All in all, this seems like a question of local policy.  Ideally the modes
would be flexibly chosen by admins, or else constrained more precisely by
SELinux policy or suchlike.  But I have no axe to grind on the subject with
this particular change.  I care more that the feature gets in and at least
root can use it, than about the permissions question.

Thanks,
Roland
-
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/