linux-kernel - Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

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: <20111107195428.GA5362@albatros>
Date:	Mon, 7 Nov 2011 23:54:28 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Eric Paris <eparis@...isplace.org>
Cc:	kernel-hardening@...ts.openwall.com, Valdis.Kletnieks@...edu,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-security-module@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to
 /proc/interrupts

On Mon, Nov 07, 2011 at 14:48 -0500, Eric Paris wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> > On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> 
> > As to procfs, I see no real need of adding mode/group mount option for
> > global procfs files (/proc/interrupts, /proc/stat, etc.) - it can be
> > done by distro specific init scripts (chown+chmod).  I don't mind
> > against such an option for the convenience, though.
> 
> While possible, the chmod+chown 'solutions' just aren't as simple as
> you pretend.  Every time one creates a chroot environment and mounts
> /proc it has be manually fixed there as well.  Same thing with a
> container.

I admit I don't fully realize all possible containers' uses, but doesn't
procfs is mounted inside of containers for only restricted full-featured
Linux distros usermods with the whole init and init scripts set?  I
didn't see any consistent usages of procfs for other things, do they
exist?

Creating separate namespaces is very useful for additional daemon
restrictions like vsftpd does it, but procfs inside of such namespace is
obviously denied by design ;)


And as procfs is a one instance per pid namespace, it has the same
permissions in all mount points, so I see no problem with chroot
(however, I find chroot not very useful with procfs inside).

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/