Multics Technical Bulletin MTB-697-01
Secure Daemon Input
To: Distribution
From: Benson I. Margulies
Date: 01/08/85
Subject: Improving the security of Message Coordinator input
1 ABSTRACT
The B2 criteria require that operators be given limited
privileges. The Multics operator command environment
does indeed limit the commands that operators may
enter. However, the Message Coordinator "reply"
facility permits operators to send arbitrary commands
to privileged processes. This MTB proposes a general
approach to restricting this feature.
This is the first revision of MTB697, containing some |
changes and clarifications requested by the design |
review. It carries change bars. |
Comments should be sent to the author:
via Multics Mail:
Margulies at either System-M, MIT, or CISL-SERVICE.
via Forum:
>udd>m>mtgs>B2 on System-M
via telephone:
(HVN) 261-9333, or
(617) 492-9333
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
MTB-697-01 Multics Technical Bulletin
Secure Daemon Input
2 SECURING PRIVILEGED DAEMONS
Daemon processes are used for several privileged applications.
The hierarchy backup, volume backup, salvager, scavenger, and
utility daemons are the primary examples. Most of these daemons
require access to functions that should not be available to
operators. Using the message coordinator quit and reply command,
though, an operator can take complete control of any of them.
There are several approaches to securing the daemons from the
operator. In some cases, there is no real need for the process
to accept and input from the operator at all. The salvager and
scavanger, for example, could get their instructions from a data
segment instead of by reading a command sent to them by admin.ec.
In other cases, the daemon could be restricted to a limited set
of commands. The backup daemons, for example, need only accept
instructions to run dumps.
| These approaches are insufficient for two reasons. First, they
| are clumsy. The "no commands" case would require special case
implementations to pass information from admin.ec to the daemon.
The LSS cases require the creation and maintenance of LSS command
lists. Second, they have operational difficulties for sites.
For example, site admin.ec's often contain additional commands
for the dumpers that could not be in the lss command list without
compromising security. Third, privileged users cannot circumvent
the restrictions to debug or resolve problems. Fourth, and
finally, there are daemons (e.g. the Utility SysDaemon) for
which an LSS is no use at all. They must run in a full Multics
environment, but must be protected from the operators.
For these reasons, we need to consider a more flexible solution.
The following sections describe a general design for controlling
access to the "daemon control" functions of login, logout, reply,
and quit.
| Using the design here, it is possible to set up any daemon
| without using an LSS. However, daemons that ask questions (e.g.,
| the volume retriever) would require extensive and complex
| additions to admin.ec. For these daemons, it is neccessary for
| the daemon itself to have some kind of limited subsystem. At
| this time, the easiest way to create such a subsystem is to use
| an LSS. Given the problems described above, we should replace
| the LSS's by a more sophisticated approach at a later time.
Multics Technical Bulletin MTB-697-01
Secure Daemon Input
3 ACL CONTROL ON MESSAGE COORDINATOR REPLY
This proposal is based on the observation that the system has
information about the source of reply and quit commands that can
be used to control access. We will control message coordinator
replies in two steps. First, construct an access name based on
the source of the command. Second, use this access name to check
access to an object.
3.1 Determining an access name
This section specifies the construction of special access names
for use in checking access in the message coordinator. There are
two new conventions that are used here. First, if an identified
and authenticated user-id is not available, then a special name |
beginning with "_" is used for the Person component of the access |
name. Second, the "Operator" project, already documented for
ordinary login by operators, will be used as the Project
component for operators logged in via the "sign_on" initializer
command, and the new tag "o" will be used for the Tag.
The following list describes all the sources of daemon
control commands and the access name that will be used when
checking access:
Ordinary Operator Commands:
An operator typing the reply or quit command on an
initializer terminal or the bootload console. If the
operator is not logged in, then the special access name |
"_Unidentified.Operator.o" is used. Note the use of |
the special person-id "_Unidentified". If the operator |
is logged in, then "Person.Operator.o" is used. This
permits selective control based on the individual
operator.
Exec commands:
An operator typing an "exec" (x) command on an
initializer terminal or the bootload console. The
admin ec, or another ec that it calls, uses sc_command
to execute a daemon control command. In this case, the
access name "_Exec_Command.Operator.o" is used. Note |
the use of the special person-id "_Exec_command". A |
special access name here reflects the fact that the
admin ec is built by trusted staff, and can be assumed
to only permit the operators to do a suitably
restricted set of things.
sc_commands in admin mode:
An operator has entered admin mode, and used sc_command
MTB-697-01 Multics Technical Bulletin
Secure Daemon Input
to enter a daemon control command. In this case, the
access name is "Initializer.SysDaemon.z", since admin
mode is equivalent to full control of the system.
send_admin_command sc_commands:
A privileged user has send an admin command. In this
case, the privileged user's access name is used
verbatim.
These access names allow administrators to express precise
distinctions. A typical approach would be to deny access to
| "*.Operator.o", and then to grant it to
| "_Exec_Command.Operator.o". Then the neccessary functions would
| be put in the admin exec_com, and operators would never type
Multics commands to daemons.
3.2 Objects of control
An extended object ACS segment will be used to hold the ACL
for each message coordinator source. The extended object model
is used because the standard segment "rew" bits cannot be used to
describe the different access modes that must be defined for a
message coordinator source. Since these modes (defined below)
are unique to the message coordinator, the unique suffix ".mcacs"
is used instead of ".acs."
To determine the effective access of the access name to the
daemon source, the Message Coordinator will look at the extended
acl of the segment >sc1>mc_acs>SOURCE_NAME.mcacs. For example,
if the Utility daemon is logged in on source "ut", then the acs
would be >sc1>mc_acs>ut.mcacs.
mcacs segments are extended objects, but they are not ring
protected in this implementation. The extended object paradigm
is used only to provide more access modes that rew.
Suffix_mcacs_ will define the following ACL modes:
r REPLY access, permits the user to reply to the daemon.
q QUIT access, permits the user to send a quit to the
daemon.
c CONTROL access, permits the user to log the daemon in
and out. If an initializer new_proc command is ever
defined for daemons, then this mode will control it.
d DAEMON access, permits a DAEMON to log in on this
source. This mode controls the association of daemon
names with message coordinator sources. For an
Multics Technical Bulletin MTB-697-01
Secure Daemon Input
operator to log Daemon A in on source B, the operator
must have c access on the source and the Daemon must
have l access.
4 IMPLEMENTATION DETAILS
The acct_start_up.ec will create the mc_acs directory, and put
acs segments in it for all the daemons manipulated in the
standard admin.ec. For the Salvager, Scavenger, backup, and
Utility daemons, it will set the acl to:
crq Initializer.SysDaemon.z
crq _Exec_Command.Operator.o
crq *.SysMaint
crq *.SysAdmin
cdrq Backup.SysDaemon.z (or whatever daemon is to log in here)
null *.*.* *
*
The IO daemon, who has a limited command environment, will give
rcq to *.*.o.
There will be a new installation_parm:
"validate_daemon_commands". When this parameter is set to "on",
the reply, quit, login, and logout commands will:
* Require that the segment >sc1>mc_acs>SOURCE.mcacs exist
before logging in a daemon on the source.
* Check the extended ACL on the mcacs segment for the access
of the special user name defined above, and forbid the
command if the required access is missing. Demand that the
Daemon to be logged in have "d" effective access to the
segment.
The admin.ec will include the following new exec commands. Note |
that we handle volume and hierarchy backup identically, even |
though volume backup still has an LSS. This is intended to |
reduce confusion. |
Name: x wakeup_dump
Function: causes a volume or hierarchy incremental daemon to
wake up and make a dump pass.
Usage: x wakeup_dump SOURCE_NAME
Where SOURCE_NAME may be either "bk", "vinc", or other message
coordinator source names defined by your site.
MTB-697-01 Multics Technical Bulletin
Secure Daemon Input
Name: x end_dump
Function: causes a volume or hierarchy incremental daemon to
finish an incremental dump, detaching its tape and cleaning up.
Usage: x end_dump SOURCE_NAME
Where SOURCE_NAME may be "bk", "vinc", or other names message
coordinator source names defined by your site.
5 OTHER DOCUMENTATION ISSUES
The Op Guide must be changed to use the initializer logout
command to log non-I/O daemons out rather than "r FOO logout".
The SysAdmin procedures book, in the security section, must
explain the mcacs segments and how to set them up for new
daemons. It must note that a B2 security level requires that the
"validate_daemon_commands" installation_parm be turned on. The
RefGuide must add .mcacs segments to its list of system object
types.
6 OTHER OPPORTUNITIES
Given this design, it would be very simple to add distributed
control of Daemons. A new as_request would allow a user to
submit a daemon control command. The .mcacs segments could be
checked for the user's access. This feature is NOT required for
B2. The following command specification is provided on that
basis:
Name: send_daemon_command
Function: Sends a command to a specified daemon process for
execution, or requests that a specified daemon process be logged
in, logged out, or have its process terminated.
Usage: send_daemon_command SOURCE_NAME {-control_args}
COMMAND_LINE
Where: SOURCE_NAME
is the Message Coordinator source name on which a daemon is
logged in or is to be logged in.
COMMAND_LINE
is a line of input to be sent to the daemon via the message
coordinator.
Multics Technical Bulletin MTB-697-01
Secure Daemon Input
Control arguments may be chosen from the following:
-login USER.PROJECT
Requests that the specified user be logged in as a daemon on MC
source SOURCE_NAME.
-logout
Requests that the specified daemon be logged out.
-quit
Requests that the specified daemon be sent a quit signal.
-new_proc
Requests that the specified daemon's process be terminated.
ACCESS REQUIRED For -login, -logout, and -new_proc, the user must
have "c" (control) effective access to
>sc1>mc_acs>SOURCE_NAME.mcacs. For -quit, the user must have "q"
(quit) effective access. For a command line, the user must have
"r" (reply) effective access. In addition, for -login, the
USER.PROJECT specified must have "d" (daemon) effective access to
SOURCE_NAME.mcacs, and must have the daemon attribute in the pdt.
7 OTHER OTHER OPPORTUNITIES
Design proposals have been floating around to apply a similiar
scheme to the multiplexer commands, and indeed to provide a
general way to specify that a given user be permitted to send the
initializer a particular command line. These ideas are not
addressed at all in this design. Note, though, that if the
as_request is implemented, then a site can create a daemon that
accepts commands (defined in an LSS) from users and then turns
around and uses send_admin_command to execute them.
8 THIS IS A CONSERVATIVE APPROACH
The author is well aware that the existing message coordinator is
a crock, and that an inner ring subsystem is a long overdue
replacement for the current collection of system_low ring four
segments in >sc1 that must be writable by all daemons. However,
the B2 criteria do not REQUIRE that we address the larger
problem. The ACL modes proposed here will be adaptable to some
design for a true inner ring multi-class design for passing input
and output to and from daemons. The rest will just have to wait.
MTB-697-01 Multics Technical Bulletin
Secure Daemon Input
| 9 MISCELLANEOUS CHANGES
| The volume backup LSS segments will be renamed to have more
| revealing names. volume_retriever will be renamed to
| volume_retriever_lss, volume_reloader to volume_reloader_lss, and
| volume_dumper to volume_dumper_lss.
| 10 TESTING
| This functionality will be tested manually, by manipulating the
| ACL's (and existence) of .mcacs segments and trying to submit
| commands.