From owner-freebsd-security Tue Nov 17 12:52:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11306 for freebsd-security-outgoing; Tue, 17 Nov 1998 12:52:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11300 for ; Tue, 17 Nov 1998 12:52:54 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40335>; Wed, 18 Nov 1998 07:51:52 +1100 Date: Wed, 18 Nov 1998 07:52:13 +1100 From: Peter Jeremy Subject: Re: Would this make FreeBSD more secure? To: security@FreeBSD.ORG Message-Id: <98Nov18.075152est.40335@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Albsmeier wrote: >I just was alarmed by xlockmore that a program runs setuid root all the time >only to check the password the user enters. In the case of xlockmore (and similar programs), the logical approach would seem to be to split the functionality into two processes: the parent process remains privileged(*), but all it would do is seize the keyboard/mouse, blank the screen and spawn children to actually display the pretty patterns. The children don't need to be priviledged, and if one crashes, the parent can just start another. An alternative approach would be to have the entire saver run non- privileged and call a privileged program to check the password. Securely writing the password checking program (so it couldn't be used for password cracking) is non-trivial. > And, regardless whether xlockmore >has known bugs or not, xlockmore-4.10 definitely does have bugs - several of the standard saver modes will die with SIGFPE (suddenly unlocking your screen). (*) Currently, this means setuid root, but all it needs is sufficient privileges to validate a password. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message