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]

Date:	Tue, 8 Nov 2011 21:41:54 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Eric Paris <eparis@...isplace.org>,
	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
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to
 /proc/interrupts

On Tue, Nov 08, 2011 at 13:23 +0000, Alan Cox wrote:
> > /proc/{interrupts,stat} are 0444, which may be used by local attacker to
> > learn statistical information about user's keystrokes, including the
> > passwords.
> 
> So the distro can chmod it 0400

Sorry, but I miss the logic.  Why do you think it's better to leave the
known unsecure defaults and rely on distros fix the permissions?  Why
not restrict it to the secure defaults and leave the decision who to
trust (i.e. all users, only current user, nobody) to distros?  The
decision has to be done either way, but in the 1st case the harm of lack
of chmod is much more significant.

> > /dev/pts/* and /dev/tty* leak the same timing information in inode's
> > atime and mtime.
> 
> That one is trickier. I don't think it is a real leak because the last
> update timing info is in seconds granularity so is pretty useless for
> that.

No, I see the precise counters:

S=''; while :; do N=`stat -L /dev/pts/3 | sed -n 5p`; [ "$N" != "$S" ] && echo "$N"; S=$N;  done

Access: 2011-11-08 21:25:41.219869215 +0400
Access: 2011-11-08 21:25:41.249869259 +0400
Access: 2011-11-08 21:25:41.289869313 +0400
Access: 2011-11-08 21:25:41.329869368 +0400
Access: 2011-11-08 21:25:41.369869433 +0400
Access: 2011-11-08 21:25:41.399869479 +0400
Access: 2011-11-08 21:25:41.439869532 +0400
Access: 2011-11-08 21:25:41.479869591 +0400
Access: 2011-11-08 21:25:41.519869655 +0400
Access: 2011-11-08 21:25:41.549869697 +0400

> The atime/mtime behaviour is however required ABI and used by
> applications so can't simply go away.

Sure, we cannot remove atime/mtime from struct stat for ttys, but we can
leave these fields zero (or equal to any const sane date) if we know
that the tty owner and the process belong to different security domains
(euid check or smth. like may_ptrace()).  The quesion here is: are there
users of checking time counters of _foreign_ ttys?  If no, leaving these
counters blank will not break anything.

> > Do we want to restrict permissions of interrupts/stat and remove atime
> > and mtime from ttys and relax these permissions when revoke() is introduced?
> 
> revoke makes no difference I can see to either of these, they appear to
> be a completely unrelated discussion.

/proc/$PID/* will certainly benefit from revoke() - all ptrace check
could be made at open time, not on every read()/write() invocation.

/proc/* will benefit from revoke() if the permission logic is
implemented as Linus wants to see it - as dynamically re-chown'ed files,
which invalidate old fds on re'chown.

tty issue is indeed unrelated, sorry for the confusion.

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/