🚀 go-pugleaf

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>We wish to make mount and umount available to two or three non-root accounts.
>The plan is create a C code fork/exec wrapper that does the following:

>	1.  Verifies that the euid is root.
>	2.  Verifies that the uid is one of the "privileged" users.
>	3.  Forces argv[0] to be /usr/etc/(u)mount.
>	4.  Does an execv(3) -- NOT execvp(3) -- to run the argv.

>The program itself is setuid root, mode 4711, so that the binary image
>cannot be copied and compromised:
>	-rws--x--x  1 root        24576 Aug 17 11:51 mmount

>I believe this to be secure.  Can someone claim otherwise?
Additionally, you should make some provisions, that the filesystems
which could be mounted by the users could be only mounted with option "nosuid".
(This forbids setuid execution on those mountpoints).

If your system doesn't support that option, you are in trouble.
Its really no problem for an advanced user, to put a sh onto a
floppy, and make it setuid root. You could forbid access to the raw
floppy, so that nobody could fiddle around with an unmounted filesystem,
but that's no real security, as you could fiddle with the bits on any dump PC.

Sincerely,
Klaus Steinberger

--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

The following were derived from Matt Bishop's "How to Write a Setuid
Program" paper:

Isolate code which needs to be run setuid or setgid in a separate 
executable or function when possible.

Reset userid and groupid to that of the person running the program as soon 
as possible.

Be as restrictive as possible in selecting the UID and GID.

Reset effective UID and GID and close all unnecessary file
descriptors before calling exec, popen, system and any other command
that invokes another process.

Carefully validate any user supplied arguments to exec, system or popen.

Make no assumptions about environment variables. At a minimum, verify or
override PATH, IFS and SHELL. In some versions of UNIX,
overriding environment variables for shared libraries such as
LD_LIBRARY_PATH and LD_PRELOAD on SUN is also necessary.

It is not safe to use creat or functions that use creat for locking.

Catch ALL signals except SIGKILL and SIGCLD.

Check all function returns for errors and abort if anything is wrong.

Programs interrupted during file creation can leave a file owned by the 
effective user rather than the real user. Do not assume that a creat 
followed by a chown is safe.

Strip the program and install it with other mode "1" so strings
or a similar program cannot be used on it.

Consider logging the real uid, tty, time executed and program name each 
time the setuid program is run.

-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist

k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:

>buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>>We wish to make mount and umount available to two or three non-root accounts.
>Its really no problem for an advanced user, to put a sh onto a
>floppy, and make it setuid root. You could forbid access to the raw
>floppy, so that nobody could fiddle around with an unmounted filesystem,
>but that's no real security, as you could fiddle with the bits on any dump PC.
I have a similar question but with mount -t pcfs on the Sun- Since it is
mounting a Dos filesystem, and since there is no ownership info on a dos
disk ( and no suid) Is it safe from floppy games (other than rebooting
from the floppy of course)
ie,
execlp("/etc/mount","mount","-t","pcfs","/dev/fd0","/pcfile",(char*)0)
Bill Unruh
unruh@physics.ubc.ca

In <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@fsrg.bear.com writes:
>We wish to make mount and umount available to two or three non-root accounts.
>The plan is create a C code fork/exec wrapper that does the following:
>
>	1.  Verifies that the euid is root.
>	2.  Verifies that the uid is one of the "privileged" users.
>	3.  Forces argv[0] to be /usr/etc/(u)mount.
>	4.  Does an execv(3) -- NOT execvp(3) -- to run the argv.
>
>The program itself is setuid root, mode 4711, so that the binary image
>cannot be copied and compromised:
>	-rws--x--x  1 root        24576 Aug 17 11:51 mmount
>
>I believe this to be secure.  Can someone claim otherwise?

What happens when your user come happily trotting along with media
containing a setuid-root program of their own devising?  There are a
number of ways they could set up such a disk, and a whole lot of things
they could do after mounting it :-(.

Are you controlling the allowable mount-points, such that they can't
overmount /etc with a disk containing a passwd file with no root password?
Or overmount /usr/etc with a umount of their own devising which your
setuid program will now run for them with euid=0?

Are you verifying that umount requests are not for something that's
supposed to stay mounted?

Note also that one of the basic principles of paranoia is that no list of
possible attacks can ever be exhaustive.  There are quite a number of
general precautions and potential loopholes with any setuid-root program,
in addition to the above few points unique to (u)mount in particular.
-- 
Anthony DeBoer       adb@geac.com | uunet!geac!adb | GEM: ANTHONY.DEBOER

In <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@fsrg.bear.com writes:

    We wish to make mount and umount available to two or three non-root
    accounts.

Setuid issues aside, make sure that they are judicious in protection of
their accounts. Anything you base on trusting them goes out the window
if their accounts can be compromised.

Rick

unruh@physics.ubc.ca (William Unruh) writes:

>ie,
>execlp("/etc/mount","mount","-t","pcfs","/dev/fd0","/pcfile",(char*)0)

% cp /bin/sh /tmp/mount_pcfs
% set path = ( /tmp $path)
% <your-mount-program>
# 

When the environment is concerned there are two basic rules:

	- if you spawn a process as the original user - keep it.
	  (E.g., xterm, screen)
	- if you spwan a process as another user - kill it TOTALLY
	  (E.g., sendmail)

Programs as su & login are a bit different. I the normal case
they give access as another user. In that case no special care is
needed. Su & login must take care that a number of special
env vars are filtered. Which vars depends largely on the OS.

To give an example of really weird misuse of env vars (when using a C-shell
script as ``login shell'' of a user without a password).

/bin/somescript is a script that performs a root function for users
of a system. It is a C-shell script.

someuser::0:0:Pseudo user to perform Somefunction:/:/bin/somescript

Normal usage:

% su someuser
Thank you for performing some function!!

Now watch this:

% setenv TERM '`/bin/chmod 666 /etc/passwd; echo done > /dev/tty`'
% su someuser
done
<hangs-type your intr char>

The point is this: you should totally clean out the environment.
You have no way of knowing what variables are used and/or will
be used in the future. Not just junk IFS, cleanup PATH, 
remove the lot.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

In article <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

   I believe this (mmount) to be secure.  Can someone claim otherwise?

I should have more fully qualified who and what the "non-root" users were
doing.  They happen to be operators who know the root password anyway.  We just
want to provide them with a facility that they can use with their regular IDs
in order to avoid having to become root.

In any case, the objective is to see if someone other than the trusted users
can (ab)use the mmount facility to acquire a root privilege command interface
of some sort.

The program need only insulate itself from surreptitious undermining; once the
user has been *authenticated*, then *authorization* and capabilities -- such
as mounting setuid floppy media, overmounting existing mounts, umounting
critical filesystems, etc. -- is another matter that can be controlled from
inside the program.

Here, then, is a simple version of mmount.c:

---8<------8<------8<------8<------8<------8<------8<------8<------8<---

/*
Here is a "model" safe setuid program -- thanks to all who sent
me mail with suggestions.  Features include:

1.  All sigs except SIGKILL and SIGCHLD shut down.
2.  All file descriptors except for stdin, out, & err closed prior to exec.
3.  "Trusted environment" only is passed via exeve().
4.  Static linking to be EXTRA safe; eliminates the dynamic load issue.

Edit the obvious things (trusted_user, etc.) and compile this program with:
cc mmount.c -Bstatic -o mmount

The binary should be stripped and chmod-ed to 4711 to prevent strings(1)
from being run on it.  It works just fine on SunOS 4.1.1 using the plain
ol' /bin/cc C compiler.  I left in some debugging printf()s; these would
be eliminated in a "production" version.

Can anyone add anything else?  Are we secure yet?
*/

#include <stdio.h>
#include <signal.h>

#include <pwd.h>
#include <sys/wait.h>



static char *trusted_user = "buzz";

static char *trusted_env[] = {
      "PATH=/usr/etc",
      0
};

main(argc, argv)
int argc;
char **argv;
{
      struct passwd *uid_ent;
      int uid, euid;
      int pid, i;
      int status;
      char **p;

      /*  Prevent signal tricks: */
      for(i = 0; i < NSIG; i++) {
	    if(i != SIGKILL && i != SIGCHLD) {
		  (void) signal(i, SIG_IGN);
	    }
      }
	
      /* Prevent file descriptor tricks; close all but stdin, out, & err: */
      for(i = getdtablesize(); i > 2; i--) {
	    (void) close(i);
      }
	    

      uid = getuid();
      euid = geteuid();

      (void) printf("uid: %d\n", uid);
      (void) printf("euid: %d\n", euid);


      if(euid != 0) {
	    (void) fprintf(stderr, "This program must be setuid root.\n");
	    exit(1);
      }

      uid_ent = getpwuid(uid);

      if(strcmp(uid_ent->pw_name, trusted_user)) {
	    (void) fprintf(stderr, "Only %s may run this program.\n",
			   trusted_user);
	    exit(1);
      }


      /* Force execution of the proper mount: */
      argv[0] = "/usr/etc/mount";


      (void) printf("argv: ");
      for(p = argv; *p != (char *)0; p++) {
	    (void) printf("[%s] ", *p);
      }
      (void) puts("");
      
      switch(pid = fork()) {
	  case -1:
	    return -1;

	  case 0:  /* child! */
	    (void) execve(argv[0], argv, trusted_env);

	    _exit(1);  /* Didn't execute! */
	    
	  default:  /* parent! */
	    break;
      }

      pid = wait(&status);

      if(WIFEXITED(status)) {
	    (void) fprintf(stderr, "child pid %d exited w/code %d\n",
			   pid, WEXITSTATUS(status));
      } else if(WIFSIGNALED(status)) {
	    (void) fprintf(stderr, "child pid %d recv'd signal %d\n",
			   pid, WTERMSIG(status));
      } else {
	    fprintf(stderr, "child did something else!\n");
      }
}

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>Here is a "model" safe setuid program -- thanks to all who sent
>me mail with suggestions.  Features include:
>[...]
>Can anyone add anything else?  Are we secure yet?

Besides closing file descriptors > 2, you will want to make sure that
file descriptors 0,1,2 are open.  Strange things can happen otherwise.
The following code fragment should do:

#include <sys/types.h>
#include <sys/stat.h>
 ...

    struct stat st;
    int     i;

    /* Make sure fd 0,1,2 are open. */

    for (i = 0; i < 3; i++) {
	if (fstat(i, &st) == -1 && open("/", 2) != i) {
	    perror("open /");
	    exit(1);
	}
    }

In article <BUZZ.92Aug19163601@toxicavenger.bear.com> buzz@fsrg.bear.com writes:
>In article <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@toxicavenger.bear.com (Buzz Moschetti) writes:
>
>   I believe this (mmount) to be secure.  Can someone claim otherwise?
>
>I should have more fully qualified who and what the "non-root" users were
>doing.  They happen to be operators who know the root password anyway.  We just
>want to provide them with a facility that they can use with their regular IDs
>in order to avoid having to become root.

By doing this, you implicitly assume that they don't log in and leave
their terminals unattended.  Because you have this program available,
each of their accounts has most of the same risks as the root account.

>In any case, the objective is to see if someone other than the trusted users
>can (ab)use the mmount facility to acquire a root privilege command interface
>of some sort.

Much of the program you posted is defending against attacks that a trusted
user probably won't use.  But it doesn't defend against attacks that
are about _what_ you are mounting/unmounting.  So it looks to me like
an su that doesn't need a password for certain users would be just as useful
and just as risky.

>The binary should be stripped and chmod-ed to 4711 to prevent strings(1)
>from being run on it.  It works just fine on SunOS 4.1.1 using the plain
>ol' /bin/cc C compiler.

If you have BSD-like groups, you might make a group of trusted users
and make this program 4710 belonging to that group.

>      uid_ent = getpwuid(uid);
>
>      if(strcmp(uid_ent->pw_name, trusted_user)) {
>	    (void) fprintf(stderr, "Only %s may run this program.\n",
>			   trusted_user);

I think it is unwise to hard code the name of the trusted user into
this program.  The trusted user may leave, being replaced by somebody
of the same name.  Or the program may be ported to another machine
where that name was used by someone else.  (Some software you get off
the net has this bug in it. :)

Mark S.

Your approach increases the vulnerability of the system to Trojan horse
attacks.  In theory, a user running as root should be extra careful
about what programs he runs, what's in his path, etc.

But now any program run by your authorized users in their normal use
of the system can execute the mount command.

--


Marc Auslander       (IBM)<marc@marc.watson.ibm.com>      914 784-6699
                     (Internet)<marc@watson.ibm.com>