From owner-freebsd-security Sat Apr 18 09:19:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06736 for freebsd-security-outgoing; Sat, 18 Apr 1998 09:19:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06715 for ; Sat, 18 Apr 1998 16:19:05 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA04012 for ; Sat, 18 Apr 1998 12:19:03 -0400 (EDT) Date: Sat, 18 Apr 1998 12:18:57 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: suid/sgid programs Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-691075835-892916337=:15725" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII One possible option for a security configuration program would be to allow the user to selectively enable/disable setuid programs on their machine. I have attached a list of suid and sgid programs found on a fairly default looking -stable machine from last night, roughly categorized into common sets. We note that it is particularly important that programs that are hard links of one another be in the same category, if the user is trying to enable/disable them :). My thoughts on choices for setuid were: 1) Disable setuid 2) Enable setuid, but restrict execution to wheel 3) Enable setuid for all In some cases (shutdown), option (2) is already the current arrangement. Depending on the system, policy for each set of binaries might vary. One thing I'd like to see in the final version is a distinction between "definition of policy" and "application of policy". I.e., The user runs one program to define their policy. This generates a config file that can now be applied to the machine (or other mahines). Someone suggested Dialog as an interface for doing this. This seems reasonable to me -- dialog does not look particularly hard to use :). Requiring X is clearly not the correct course of action. For sgid, it is not clear whether the two options aren't just 'enable' and 'disable', as we can't really change the group on them to limit use :). Also, there are a few suid/sgid programs that probably don't have to be -- ncrcontrol, for example. Most *control programs are not suid/sgid, and require the user to be uid0 to run them. Is there a reason for this difference here? We note also that a fairly large chunk of suid/sgid programs are UUCP programs -- something that a majority of FreeBSD users (I would guess?) do not use. In terms of reducing risk, disabling suid/sgid on these programs as part of a hardening process, if they are not needed, would be a great boon. The suid and sgid lists are formatted as follows: category:binary,binary... If I've missed any, please let me know. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ --0-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=suid Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Y3U6L3Vzci9iaW4vY3UNCm1hbjovdXNyL2Jpbi9tYW4NCnV1Y3A6L3Vzci9i aW4vdXVjcCwvdXNyL2Jpbi91dW5hbWUsL3Vzci9iaW4vdXVzdGF0LC91c3Iv YmluL3V1eCwvdXNyL2xpYmV4ZWMvdXVjcC91dWNpY28sL3Vzci9saWJleGVj L3V1Y3AvdXV4cXQNCnBlcmw6L3Vzci9iaW4vc3VpZHBlcmwsL3Vzci9iaW4v c3Blcmw0LjAzNg0KYXQ6L3Vzci9iaW4vYXQsL3Vzci9iaW4vYXRxLC91c3Iv YmluL2F0cm0sL3Vzci9iaW4vYmF0Y2gNCnBhc3N3ZDovdXNyL2Jpbi9jaHBh c3MsL3Vzci9iaW4vY2hmbiwvdXNyL2Jpbi9jaHNoLC91c3IvYmluL3lwY2hw YXNzLC91c3IvYmluL3lwY2hmbiwvdXNyL2Jpbi95cGNoc2gsL3Vzci9iaW4v bG9jaywvdXNyL2Jpbi9wYXNzd2QsL3Vzci9iaW4veXBwYXNzd2QNCnNrZXk6 L3Vzci9iaW4va2V5aW5mbywvdXNyL2Jpbi9rZXlpbml0DQpsb2dpbjovdXNy L2Jpbi9sb2dpbg0KcXVvdGE6L3Vzci9iaW4vcXVvdGENCnJzaDovdXNyL2Jp bi9ybG9naW4sL3Vzci9iaW4vcnNoLC9iaW4vcmNwDQpjcm9udGFiOi91c3Iv YmluL2Nyb250YWINCnN1Oi91c3IvYmluL3N1DQpscHI6L3Vzci9iaW4vbHBx LC91c3IvYmluL2xwciwvdXNyL2Jpbi9scHJtDQpzZW5kbWFpbDovdXNyL2Jp bi9uZXdhbGlhc2VzLC91c3IvYmluL21haWxxLC91c3IvYmluL2hvc3RzdGF0 LC91c3IvbGliZXhlYy9tYWlsLmxvY2FsLC91c3Ivc2Jpbi9zZW5kbWFpbCwv dXNyL3NiaW4vcHVyZ2VzdGF0DQprZXJiZXJvczovdXNyL2Jpbi9yZWdpc3Rl cg0KbXVsdGljYXN0Oi91c3Ivc2Jpbi9tcmluZm8sL3Vzci9zYmluL210cmFj ZQ0KcHBwc2xpcDovdXNyL3NiaW4vcHBwLC91c3Ivc2Jpbi9wcHBkLC91c3Iv c2Jpbi9zbGlwbG9naW4NCnRpbWVkOi91c3Ivc2Jpbi90aW1lZGMNCnBpbmc6 L3Vzci9zYmluL3RyYWNlcm91dGUsL3NiaW4vcGluZw0Kcm91dGU6L3NiaW4v cm91dGUNCnNodXRkb3duOi9zYmluL3NodXRkb3duDQoNCg== --0-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sgid Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Y3U6L3Vzci9iaW4vY3UNCnV1Y3A6L3Vzci9iaW4vdXVzdGF0LC91c3IvbGli ZXhlYy91dWNwL3V1Y2ljbw0KZGY6L2Jpbi9kZg0Ka21lbTovYmluL3BzLC9z YmluL2NjZGNvbmZpZywvc2Jpbi9kbWVzZywvdXNyL2Jpbi9mc3RhdCwvdXNy L2Jpbi9pcGNzLC91c3IvYmluL25ldHN0YXQsL3Vzci9iaW4vbmZzc3RhdCwv dXNyL2Jpbi9zeXN0YXQsL3Vzci9iaW4vdG9wLC91c3IvYmluL3VwdGltZSwv dXNyL2Jpbi92bXN0YXQsL3Vzci9iaW4vdywvdXNyL3NiaW4vaW9zdGF0LC91 c3Ivc2Jpbi9uY3Jjb250cm9sLC91c3Ivc2Jpbi9wc3RhdCwvdXNyL3NiaW4v c3dhcGluZm8sL3Vzci9zYmluL3RycHQNCnR0eTovc2Jpbi9kdW1wLC9zYmlu L3JkdW1wLC9zYmluL3Jlc3RvcmUsL3NiaW4vcnJlc3RvcmUsL3Vzci9iaW4v d2FsbCwvdXNyL2Jpbi93cml0ZQ0KbHByOi91c3IvYmluL2xwcSwvdXNyL2Jp bi9scHIsL3Vzci9iaW4vbHBybSwvdXNyL3NiaW4vbHBjDQpnYW1lczovdXNy L2dhbWVzL2RtDQoNCg== --0-691075835-892916337=:15725-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message