linux-kernel - Re: tty: add 'active' sysfs attribute to tty0 and console device

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, 16 Nov 2010 23:04:30 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Lennart Poettering <mzxreary@...inter.de>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Werner Fink <werner@...e.de>,
	Jiri Slaby <jslaby@...e.cz>
Subject: Re: tty: add 'active' sysfs attribute to tty0 and console device

> And as long as we have no problem with letting everybody know who is
> logged in, and on which tty we shouldn't waste brain cells on discussing
> whether it is a problem if they also find out whether that login is
> currently active or not.

Thge current kernel supports you not knowing who is using which console,
furthermore there are environments where this is both used and the
current console is *very* important information.

The fact you lack the knowledge of such environments or even the wit to
figure them out doesn't mean they don't exist.

> Also, sysfs supports perms just fine. If you don't want people to see
> it, then just chmod 600 the sysfs file, and nobody can see it
> anymore. That's a trivial thing to do. It's a lot more difficult to hide
> who's logged in, since the user who is logged in takes possession of the
> tty file which everybody can see and stat(), even if not open().

Then it needs to start 0600 - security starts by failing safe.

> This is really a pointless discussion. Security is not an issue
> here. Which tty is currently active is completely boring information,
> and the least we should think about. 

Wrong. That's the kind of sloppy attitude that causes bugs, poor code and
security holes. It's the kind of arrogant "it only gets used like I say
it does so screw the rest of you" attitude that the certain desktops are
wrecked by.

So we *are* going to discuss the security, we are going to discuss the
permissions and we are going to discuss the permissions management model
you are trying to implement because when we've done that there is a good
chance of finding a model that a) works b) is secure and c) solves your
specific problem case.

Alan
--
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/