linux-kernel - Re: questions to planned lock-functionality for vts

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Mar 2015 11:29:25 +0100
From:	simone.weiss@....de
To:	"Greg KH" <gregkh@...uxfoundation.org>
Cc:	helene.gsaenger@...dium.fau.de, jslaby@...e.cz,
	dh.herrmann@...il.com, daniel.vetter@...ll.ch,
	peter@...leysoftware.com, tiwai@...e.de, mark.d.rustad@...el.com,
	joe@...ches.com, linux-kernel@...r.kernel.org,
	linux-kernel@...cs.fau.de, simone.weiss@....de,
	helene.gsaenger@...dium.fau.de
Subject: Re: questions to planned lock-functionality for vts


> Wait, what's wrong with the existing functionality?

Userspace programms for screensavers can potentially be bypassed
- if my scrennsaver dies, for example by segfault, my screen is unlocked
- Redirection is only possible in Kernel, because a vt switch can only
  be prevented there
Also it would make the implementation of a Secure-Acess-Key possible
(could also redirect to VT12)

>> It should behave like:
>> If user A owns e.g. vt2, A is able to lock vt2 and unlock it again.
>> This is realized by a userspace programm that calls ioctl, which the
>> above
>> mentioned added cases VT_LOCK and VT_UNLOCK.
>> Another user(that is not root) wouldn't be allowed to un-/lock vt2.
>> If anybody wants to change to a looked VT he gets redirected to vt12.
>> At vt12 a userspace programm (to unlock a VT) would run and ask for
>> loginname and password, if it is the password from the user that owns
>> the
>> locked terminal or from root.
>> The VT gets unlocked and the user gets directed to his terminal.
>
> Why would you want to put all of that into the kernel?

We don't want to put all of that in the kernel, the above describes only
the interaction with a userspace programm.
For the kernel it would only mean that if a vt is locked
it wouldn't allow to switch to this vt and instead switch to VT12.

Regards,
Simone Weiss

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