Re: /sbin/reboot and secmodel

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        Hello.  What does the secmodel have to work with in terms of
authorization tokens?  What I'm thinking here is that I understand that it
is a two stage process to reboot a system, first send signals to all
processes, then actually reboot the system.  While it might not be
desirable to always allow a given user who ordinarily can't send signals to
arbitrary processes to do so under the circumstance when he's rebooting the
system, it's not clear the sec model, as currently implemented, provides
enough richness in the authentication and authorization tokens to allow a
sec policy to be written tthat can evaluate that the calling process is the
shut down program, that the calling user is permitted to run the shutdown
program, and that tasks associated with this procedure, i.e. those routines
the shutdown program calls, should be permitted.
        As I think about it, this is precisely why the Set[GU]id bits came
into being in the first place.  Specifically, the reason is that system
calls are supposed to live independently of each other, but programs can be
written in user space to use those system calls as building blocks to do 
interesting
things.
        In this case, you want to shut the machine down, and that process is a
multi-step process.  You only want the steps to be performed as an atomic
operation, i.e. you don't want the user to be able to perform step 1,
signal processes, without also performing step 2, rebooting.
        Set[GU]id gets around the problem of building this complex concept into
the kernel, by authorizing programs, not users, to do special tasks, even
though the kernel only knows how to deal with user level permissions.
        As Smb mentioned, one way around this problem, without putting too
much goo into the kernel, is to do some sort of reboot_authorize(2) which
checks to see if the caller is allowed to make the reboot call.  Part of
that new call could be to register the program's desire to make a reboot(2)
call, and thus to allow it to signal all processes.  I'm thinking the
reboot_authorize(2) call could return some sort of opaque token which could
then be passed to the signal(2) call to let  it know that this call is part
of a pending operation.  But, as I think about it, this technique doesn't
really work that well either, since there's no guarantee that the calling
program might not abuse the system by getting permission to call reboot,
calling signal(2) and then never calling reboot.
        No, as I think about it, I think the sec model is interesting, but I
don't think it solves this particular problem, because there will always be
a need for programs to perform tasks that users cannot.
-Brian

On Mar 17,  8:25pm, Elad Efrat wrote:
} Subject: Re: /sbin/reboot and secmodel
} Brian Buhrow wrote:
} >     Hello.  I haven't looked, but I assume that reboot(8) and shutdown(8)
} > currently fetch a list of processes to signal, then signal each process in
} > turn? 
} 
} Nope, a reboot ends up in reboot(8), which calls kill(-1, ...) to send a
} a signal to all processes. It *assumes* it's "all processes" because the
} semantics say that, according to kill(2):
} 
}       If pid is -1:
}       If the user has super-user privileges, the signal is sent to all
}       processes excluding system processes and the process sending the
}       signal.
} 
} Technically what happens is that the kernel will try signaling all
} processes:
} 
}       http://nxr.netbsd.org/source/xref/sys/kern/kern_sig.c#killpg1
} 
} Here the secmodel comes into the picture, preventing (for bsd44) from
} non-root users from signaling a process they're not supposed to. So if
} you granted access to reboot(2) to user-id 1000, he would be cable to
} directly call reboot(2), but executing reboot(8) would fail as he does
} not have enough privileges to signal all processes.
} 
} > If so, then it would make sense to me to have the sec model either
} > permit or deny each signal to be sent from one process to another, based on
} > the sending process's credentials.  Since signal(2) is another system call,
} > wouldn't it make sense to just have it be another system call that the sec
} > model guards  It seems like this approach has the advantage that you don't
} > need to change the already working prorgrams, and there's a general
} > solution for the question, how can I permit an arbitrary process that's not
} > root or the current user, to send a signal to another process on the
} > system?
} 
} First, the secmodel is not guarding system calls. The secmodel is
} supposed to permit or deny operations; these may boil down to access to
} a certain syscall or not, but we're definitely not limited to that.
} 
} That said, the problem we're trying to solve is how to allow a certain
} user to reboot the system, preferably a graceful reboot via reboot(8),
} which includes sending signals to all processes to give them a chance to
} exit cleanly.
} 
} The problem is when you group the two together. If we imply that
} permission to reboot the system implies permission to send SIGTERM and
} SIGKILL to any process, the latter not necessarily done as a result of
} the former, we may be forcing secmodel authors to grant permissions they
} are not interested in to certain users, hence limiting the flexibility
} of the secmodel.
} 
} -e.
>-- End of excerpt from Elad Efrat