munge(7) - f37

1
2MUNGE(7)                  MUNGE Uid 'N' Gid Emporium                  MUNGE(7)
3
4
5

NAME

7       munge - MUNGE overview
8
9

INTRODUCTION

11       MUNGE  (MUNGE  Uid  'N'  Gid Emporium) is an authentication service for
12       creating and validating user credentials.  It is designed to be  highly
13       scalable for use in an HPC cluster environment.  It provides a portable
14       API for encoding the user's identity  into  a  tamper-proof  credential
15       that  can be obtained by an untrusted client and forwarded by untrusted
16       intermediaries within a security realm.  Clients within this realm  can
17       create and validate credentials without the use of root privileges, re‐
18       served ports, or platform-specific methods.
19
20

RATIONALE

22       The need for MUNGE arose out of the HPC cluster environment.   Consider
23       the scenario in which a local daemon running on a login node receives a
24       client request and forwards it on to remote daemons running on  compute
25       nodes  within the cluster.  Since the user has already logged on to the
26       login node, the local daemon just needs a reliable means of  ascertain‐
27       ing  the  UID  and  GID of the client process.  Furthermore, the remote
28       daemons need a mechanism to ensure the  forwarded  authentication  data
29       has not been subsequently altered.
30
31       A  common solution to this problem is to use Unix domain sockets to de‐
32       termine the identity of the local client, and then forward this  infor‐
33       mation  on  to  remote  hosts  via  trusted  rsh connections.  But this
34       presents several new problems.  First, there is no portable API for de‐
35       termining  the identity of a client over a Unix domain socket.  Second,
36       rsh connections must originate from a reserved port; the limited number
37       of  reserved  ports available on a given host directly limits scalabil‐
38       ity.  Third, root privileges are required in order to  bind  to  a  re‐
39       served  port.  Finally, the remote daemons have no means of determining
40       whether the client identity is authentic.  MUNGE solves  all  of  these
41       problems.
42
43

USAGE

45       A  process  creates a credential by requesting one from the local MUNGE
46       service, either via the munge_encode() C library call or the munge exe‐
47       cutable.  The encoded credential contains the UID and GID of the origi‐
48       nating process.  This process sends the credential to  another  process
49       within  the security realm as a means of proving its identity.  The re‐
50       ceiving process validates the credential with  the  use  of  its  local
51       MUNGE  service, either via the munge_decode() C library call or the un‐
52       munge  executable.   The  decoded  credential  provides  the  receiving
53       process  with  a  reliable means of ascertaining the UID and GID of the
54       originating process.  This information can be used  for  accounting  or
55       access control decisions.
56
57

DETAILS

59       The  contents  of  the credential (including any optional payload data)
60       are encrypted with a key shared by all munged daemons within the  secu‐
61       rity  realm.   The  integrity of the credential is ensured by a message
62       authentication code (MAC).  The credential is valid for a limited  time
63       defined  by its time-to-live (TTL); this presumes clocks within a secu‐
64       rity realm are in sync.  Unexpired credentials are tracked by the local
65       munged  daemon in order to prevent replay attacks on a given host.  De‐
66       coding of a credential can be restricted to a  particular  user  and/or
67       group  ID.  The payload data can be used for purposes such as embedding
68       the destination's address to ensure the credential is only valid  on  a
69       specific  host.   The internal format of the credential is encoded in a
70       platform-independent manner.  And the credential itself is  base64  en‐
71       coded to allow it to be transmitted over virtually any transport.
72
73

AUTHOR

75       Chris Dunlap <cdunlap@llnl.gov>
76
77

COPYRIGHT

79       Copyright (C) 2007-2022 Lawrence Livermore National Security, LLC.
80       Copyright (C) 2002-2007 The Regents of the University of California.
81
82       MUNGE  is free software: you can redistribute it and/or modify it under
83       the terms of the GNU General Public License as published  by  the  Free
84       Software  Foundation,  either version 3 of the License, or (at your op‐
85       tion) any later version.
86
87       Additionally for the MUNGE library (libmunge), you can redistribute  it
88       and/or  modify  it under the terms of the GNU Lesser General Public Li‐
89       cense as published by the Free Software Foundation, either version 3 of
90       the License, or (at your option) any later version.
91
92