File: NOTES

package info (click to toggle)
gssproxy 0.5.1-2
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 1,080 kB
  • ctags: 1,348
  • sloc: ansic: 16,369; python: 559; xml: 474; makefile: 359; sh: 79
file content (45 lines) | stat: -rw-r--r-- 1,964 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

 - How to handle mixed proxied and non-proxied credentials for one
   process?

   Idea #0: Always use the proxy or no proxy.  Period.  Use an env var to
            select mechglue config.

   Idea #1: Some mechglue magic and minor constraints on the applications.

    - mechglue needs to allow multiple providers to provide same
      mechanisms, with GSS_Acquire/Add_cred*() trying all providers for
      the desired mechanism(s) in order till one works or all fail;

    - this does not work for GSS_Init/Accept_sec_context() when using
      the default credential;

       - for GSS_Init_sec_context() just pick one provider to be first
	 for default credential and let apps that want the other
	 provider acquire a credential handle instead of using the
	 default one (e.g., ssh -o GSSAPIInitiatorCredential=...);

       - for GSS_Accept_sec_context() declare that all acceptor
	 credentials for any given mechanism must be proxied or not;

   Idea #2: Use PGSS or GSS-APIv3 so we can have a caller context handle
            via which to specify mechglue configuration.

 - SPNEGO (any pseudo-mechanism) should not be proxied, as it will
   re-enter the mechglue and call the proxy(ies) if needed (or not) as
   appropriate.


 - How to pass around ccaches ?
    We simply don't.
    1. For a user, we should probably deny init_sec_context initially, but if we
    allow it we need to create a ccache like
        /var/lib/gssproxy/cc/krb5cc_<userename>
    The user will not have direct access to the cache.
    2. For a normal service we will do the same, both accept and init contetx use
    the configured keytab and the ccache will be in
        /var/lib/gssproxy/cc/krb5cc_<servicename>
    3. For a trusted service we do the same as in 2. except when the service
    asks us to init_sec_context as a user, in that case we will try to use the
    user's ccache in /run/user/<username>/krb5cc, erroring out if it does not
    exist or is expired.