🚀 go-pugleaf

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.