From alex@big.endian.de  Sat Jul 15 01:54:53 2000
Return-Path: <alex@big.endian.de>
Received: from mout1.silyn-tek.de (mout1.silyn-tek.de [194.25.165.69])
	by hub.freebsd.org (Postfix) with ESMTP id E78A137BDA8
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Jul 2000 01:54:45 -0700 (PDT)
	(envelope-from alex@big.endian.de)
Received: from [192.168.32.33] (helo=mx1.silyn-tek.de)
	by mout1.silyn-tek.de with esmtp (Exim 3.13 #1)
	id 13DNif-0007Kw-00
	for FreeBSD-gnats-submit@freebsd.org; Sat, 15 Jul 2000 10:54:45 +0200
Received: from p3e9c1174.dip0.t-ipconnect.de ([62.156.17.116] helo=neutron.cichlids.com)
	by mx1.silyn-tek.de with esmtp (Exim 3.13 #1)
	id 13DNid-00075P-00
	for FreeBSD-gnats-submit@freebsd.org; Sat, 15 Jul 2000 10:54:43 +0200
Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10])
	by neutron.cichlids.com (Postfix) with ESMTP id 3004FAB8C
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Jul 2000 10:56:05 +0200 (CEST)
Received: by cichlids.cichlids.com (Postfix, from userid 1001)
	id 2B2C014AEB; Sat, 15 Jul 2000 10:55:10 +0200 (CEST)
Message-Id: <20000715085510.2B2C014AEB@cichlids.cichlids.com>
Date: Sat, 15 Jul 2000 10:55:10 +0200 (CEST)
From: alex@freebsd.org
Sender: alex@big.endian.de
Reply-To: alex@big.endian.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: possible bug in sh(1) with -p flag (privileged mode)
X-Send-Pr-Version: 3.2

>Number:         19946
>Category:       bin
>Synopsis:       possible bug in sh(1) with -p flag (privileged mode)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    alex
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 15 02:00:02 PDT 2000
>Closed-Date:    Fri Jun 8 05:12:08 PDT 2001
>Last-Modified:  Fri Jun 08 05:12:47 PDT 2001
>Originator:     Alexander Langer
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
FreeBSD Project
>Environment:

-current

>Description:

I think I found a possible bug  in the sh(1) -p (privileged mode) behaviour.
On the one hand, the manpage is something broken (see pr 18243).

However, this is another thing.  If I understood the -p flag correctly
from the source and the current manpage, the -p flag should turn
off different real and effective user ids (and gids).
-p turns on, that the effective uid is set TO the real uid. (and the gid's
respectively).
However, in this case, it makes no sense, that STILL /etc/suid_profile
is parsed in spite of ~/.profile(!) - in fact, -p should turn OFF
the priviledged mode behaviour, or am I wrong?

So, I suggest to use the following patch, which sets the global variable
`privileged' to 0 again, after the -p flag is given and the
effective uid/gid are set to the real ones.
This makes sh parse ~/.profile later on (in main.c), which is
the correct behaviour in my opinion.

I'll take a look at the manpage later to clarify this.

>How-To-Repeat:

n/a

>Fix:

cvs server: Diffing .
Index: options.c
===================================================================
RCS file: /home/ncvs/src/bin/sh/options.c,v
retrieving revision 1.16
diff -u -r1.16 options.c
--- options.c	2000/04/20 09:49:16	1.16
+++ options.c	2000/07/15 08:54:26
@@ -193,6 +193,7 @@
 				if (c == 'p' && !val && privileged) {
 					(void) setuid(getuid());
 					(void) setgid(getgid());
+					privileged = 0;
 				}
 				setoption(c, val);
 			}
@@ -218,6 +219,7 @@
 				if (!val && privileged && equal(name, "privileged")) {
 					(void) setuid(getuid());
 					(void) setgid(getgid());
+					privileged = 0;
 				}
 				setoption(optlist[i].letter, val);
 				return;
cvs server: Diffing bltin
cvs server: Diffing funcs

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->cracauer 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Mon Jul 17 10:47:31 PDT 2000 
Responsible-Changed-Why:  
Martin's our Bourne man. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19946 
Responsible-Changed-From-To: cracauer->freebsd-bugs 
Responsible-Changed-By: cracauer 
Responsible-Changed-When: Tue Sep 12 08:38:56 MEST 2000 
Responsible-Changed-Why:  
This PR is not really a shell bug, but a matter of security policy (sh 
has a switch -p that - when set - should allow root to su(8) to a user 
without inheriting anything from that user's dotfiles that would 
compromise root's account). 

Personally, I am not used to think of waterproofed security solutions 
and I see no reason how I should judge over the measurments such a 
flag must take to protect the user who su'ed.  Looking at bash2, it 
uses an entirely different (and apparently more though-off) approach 
towards the same problem.  I think this needs to be dicussed on 
-security. 

If anyone thinks of an appropriate solution (which includes your 
suggestion - Alexander), please have it reviewed by 
security@freebsd.org.  I will of course be happy to participiate in 
such a discussion where I can be of help and would commit and maintain 
a solution that is considered waterproofed by a substancial group of 
security-knowledgable people. 

I would also consider removing this switch as long as it's security 
gain is questionable. 
-:---F1  foo               (Text Fill)--L1--All--------------------------------- 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19946 
Responsible-Changed-From-To: freebsd-bugs->alex 
Responsible-Changed-By: alex 
Responsible-Changed-When: Sat Mar 10 09:57:13 PST 2001 
Responsible-Changed-Why:  
Assign this PR to me as a reminder to start a discussion on -security 
about it, as Martin suggested (which will of course end in a bikeshed 
and result in a IPSEC cabable truncate(1)...). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19946 
State-Changed-From-To: open->closed 
State-Changed-By: alex 
State-Changed-When: Fri Jun 8 05:12:08 PDT 2001 
State-Changed-Why:  
Further investigation tells me, that sh behaves correct. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19946 
>Unformatted:
