From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45256E1F.8030204@us.ibm.com> Date: Thu, 05 Oct 2006 15:42:07 -0500 From: Michael C Thompson MIME-Version: 1.0 To: Stephen Smalley CC: Daniel J Walsh , SE Linux , jdesai@us.ibm.com Subject: Re: [RFC PATCH] newrole suid breakdown References: <452432FA.1060009@us.ibm.com> <1160059227.2132.88.camel@moss-spartans.epoch.ncsc.mil> <452566B2.7040003@us.ibm.com> <1160079893.2132.246.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1160079893.2132.246.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Thu, 2006-10-05 at 15:10 -0500, Michael C Thompson wrote: >> Stephen Smalley wrote: >>> On Wed, 2006-10-04 at 17:17 -0500, Michael C Thompson wrote: >>>> From what I have seen, the points of possible attack (i.e. input) to >>>> newrole include: >>>> * command line options >>>> * reading the password from stdin >>>> * reading the contents of /etc/passwd and /etc/shell >>>> >>>> I doubt this is an exhaustive list. Since /etc/passwd and /etc/shell are >>>> restricted to root-only write, I've discounted these. Since we require >>>> PAM to do namespaces, which will cause PAM to handle the password check, >>>> we should be able to defer any vulnerabilities to PAM, and I would hope >>>> that PAM is secure. >>>> >>>> This leaves command line options. These are parsed with getopt_long, and >>>> are currently passed into libselinux without any scrubbing. Since >>>> SELinux doesn't apply a limit on the length of its context strings, is >>>> there any checks that need to be done before handing these strings into >>>> libselinux? >>> I don't think so. The larger concern is not the command line arguments >>> but the environment. glibc does some automatic sanitization of the >>> environment for setuid programs, but is limited in what it can do. >>> You likely want to save the environment or portions of it for >>> propagation to the newrole'd shell, reset the environment to a clean >>> state for newrole itself, and then invoke the user shell with the >>> previously saved environment. Look at other setuid programs, like su >>> and sudo, as possible examples. Also see: >>> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html >> Working towards this now. I am mimicing the behavior of su. By the time >> we invoke pam_namespace, the environment will be scrubbed clean and will >> contain a limited set of values (stardard shell related HOME, PATH, >> TERM, etc). PATH will be set to a set of trusted paths like >> /bin:/usr/bin, etc. > > Ok. Are you restoring the original environment or some portion of it > for the newrole'd shell? su has different options there for handling > environment depending on how it is called. Just a portion. I can implement the su functionality to handle these scenarios different as well if you like. >>> Since pam_namespace further executes a script (namespace.init), the >>> environment is especially critical, and you need to consider the >>> implications of how the shell handles setuid execution. For example, >>> unless namespace.init invokes /bin/sh with the -p option (privileged >>> mode), bash will reset the effective identities to the real identities >>> during startup, such that the script itself will run in the caller's >>> identity (and thus likely fail if it tries to do its job, like bind >>> mounting the .X11-unix directory into the member directory, as well as >>> creating any files or directories in the caller's uid). If you change >>> namespace.init to use the -p option, then bash will leave the effective >>> identities alone, and will ignore certain aspects of the environment >>> that would normally affect it. One might argue that pam_namespace >>> itself should do some environment cleansing, since it executes a script >>> and this won't be immediately obvious to all potential users of >>> pam_namespace. >> So I take it changing namespace.init is an acceptable solution? > > Yes, I think so. Will send a patch to the list. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.