Toni L. Harbaugh-Blackford
2002-Sep-04 15:43 UTC
uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
What do we loose by not having post-auth privsep?
What code is executed between authorization and actual setting of the
effective uid?
On Tue, 3 Sep 2002, Chris Adams wrote:
> Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at
nciaxp.ncifcrf.gov> said:
> > It appears that the integration of the sia session setup will either
> > have to be rethought or abandoned in order for privsep to work.
>
> That was the conclusion I came to a while back. I'd like to keep
> pre-auth privsep (because that works fine and does help somewhat), but I
> don't think it is possible to do post-auth privsep on Tru64, at least
> when Enhanced Security or auditing are enabled (if they aren't, I
think
> you can still do "--disable-sia", although I haven't tried
that in a
> long time now).
>
> I was hoping that Ben Lindstrom would prove me wrong (and I appologize
> for not ever getting around to helping - I've got all fifty-some list
> messages about Tru64 and privsep still saved, but work's been crazy,
I
> only have access to a Tru64 devel box at work, and this isn't a
priority
> to work with the other stuff going on). When I last looked at it in
> depth I hadn't really gotten a good handle on how privsep worked, so
I
> figured I was just missing something.
>
Where exactly *is* the privsep transition made?
At what point does the process that eventually runs do_child()
get its uid set to the real user? Could the setup_sia() routine
be moved out of the do_child() function to an earlier phase before
the uid is changed?
It appears that if setup_sia() were to be moved out of do_child()
that would mean that no pty would be passed to the session unless
creation of the pty were moved out also.
But then again whether this is worth doing depends on what we loose if
we drop post-auth privsep.
> I'd suggest the following patch against openssh-SNAP-20020826. Most
of
> it is cleanup patch from a while back that I submitted too late for
> 3.4p1 and didn't resend after that I guess. The other defines
> DISABLE_FD_PASSING when SIA is enabled, which effectively turns off
> post-auth privsep.
So if DISABLE_FD_PASSING turns privsep off, does that mean that
session_setup_sia() will be run directly by do_child(), which
at that point will be effective uid 0?
> Note that I haven't been able to try it with the
> latest snapshot, as I'm not at my devel box and I don't have the
correct
> version of autoconf installed at the moment (need the old one for some
> other stuff I've got and haven't finagled them into working
together
> yet).
>
I'll give the patch a try.
Thanks,
Toni
> diff -urN openssh-SNAP-20020826/auth-sia.c openssh/auth-sia.c
> --- openssh-SNAP-20020826/auth-sia.c Fri Apr 12 10:36:08 2002
> +++ openssh/auth-sia.c Tue Sep 3 22:03:16 2002
> @@ -45,27 +45,25 @@
> extern int saved_argc;
> extern char **saved_argv;
>
> -extern int errno;
> -
> int
> auth_sia_password(Authctxt *authctxt, char *pass)
> {
> int ret;
> SIAENTITY *ent = NULL;
> const char *host;
> - char *user = authctxt->user;
>
> host = get_canonical_hostname(options.verify_reverse_mapping);
>
> - if (!user || !pass || pass[0] == '\0')
> + if (!authctxt->user || !pass || pass[0] == '\0')
> return(0);
>
> - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, NULL, 0,
> - NULL) != SIASUCCESS)
> + if (sia_ses_init(&ent, saved_argc, saved_argv, host,
authctxt->user,
> + NULL, 0, NULL) != SIASUCCESS)
> return(0);
>
> if ((ret = sia_ses_authent(NULL, pass, ent)) != SIASUCCESS) {
> - error("Couldn't authenticate %s from %s", user, host);
> + error("Couldn't authenticate %s from %s",
authctxt->user,
> + host);
> if (ret & SIASTOP)
> sia_ses_release(&ent);
> return(0);
> @@ -77,48 +75,35 @@
> }
>
> void
> -session_setup_sia(char *user, char *tty)
> +session_setup_sia(struct passwd *pw, char *tty)
> {
> - struct passwd *pw;
> SIAENTITY *ent = NULL;
> const char *host;
>
> - host = get_canonical_hostname (options.verify_reverse_mapping);
> + host = get_canonical_hostname(options.verify_reverse_mapping);
>
> - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0,
> - NULL) != SIASUCCESS) {
> + if (sia_ses_init(&ent, saved_argc, saved_argv, host,
pw->pw_name, tty,
> + 0, NULL) != SIASUCCESS)
> fatal("sia_ses_init failed");
> - }
>
> - if ((pw = getpwnam(user)) == NULL) {
> - sia_ses_release(&ent);
> - fatal("getpwnam: no user: %s", user);
> - }
> if (sia_make_entity_pwd(pw, ent) != SIASUCCESS) {
> sia_ses_release(&ent);
> fatal("sia_make_entity_pwd failed");
> }
>
> ent->authtype = SIA_A_NONE;
> - if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) {
> - fatal("Couldn't establish session for %s from %s", user,
> - host);
> - }
> -
> - if (setpriority(PRIO_PROCESS, 0, 0) == -1) {
> - sia_ses_release(&ent);
> - fatal("setpriority: %s", strerror (errno));
> - }
> + if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS)
> + fatal("Couldn't establish session for %s from %s",
> + pw->pw_name, host);
>
> - if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) {
> - fatal("Couldn't launch session for %s from %s", user,
host);
> - }
> + if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS)
> + fatal("Couldn't launch session for %s from %s",
pw->pw_name,
> + host);
>
> sia_ses_release(&ent);
>
> - if (setreuid(geteuid(), geteuid()) < 0) {
> + if (setreuid(geteuid(), geteuid()) < 0)
> fatal("setreuid: %s", strerror(errno));
> - }
> }
>
> #endif /* HAVE_OSF_SIA */
> diff -urN openssh-SNAP-20020826/auth-sia.h openssh/auth-sia.h
> --- openssh-SNAP-20020826/auth-sia.h Fri Apr 12 10:36:08 2002
> +++ openssh/auth-sia.h Tue Sep 3 22:03:16 2002
> @@ -27,6 +27,6 @@
> #ifdef HAVE_OSF_SIA
>
> int auth_sia_password(Authctxt *authctxt, char *pass);
> -void session_setup_sia(char *user, char *tty);
> +void session_setup_sia(struct passwd *pw, char *tty);
>
> #endif /* HAVE_OSF_SIA */
> diff -urN openssh-SNAP-20020826/configure.ac openssh/configure.ac
> --- openssh-SNAP-20020826/configure.ac Tue Aug 13 20:52:11 2002
> +++ openssh/configure.ac Tue Sep 3 22:07:41 2002
> @@ -314,6 +314,7 @@
> AC_MSG_RESULT(yes)
> AC_DEFINE(HAVE_OSF_SIA)
> AC_DEFINE(DISABLE_LOGIN)
> + AC_DEFINE(DISABLE_FD_PASSING)
> LIBS="$LIBS -lsecurity -ldb -lm -laud"
> else
> AC_MSG_RESULT(no)
> diff -urN openssh-SNAP-20020826/session.c openssh/session.c
> --- openssh-SNAP-20020826/session.c Wed Jul 31 20:28:39 2002
> +++ openssh/session.c Tue Sep 3 22:03:16 2002
> @@ -1280,7 +1280,7 @@
> */
> if (!options.use_login) {
> #ifdef HAVE_OSF_SIA
> - session_setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL :
s->tty);
> + session_setup_sia(pw, s->ttyfd == -1 ? NULL : s->tty);
> if (!check_quietlogin(s, command))
> do_motd();
> #else /* HAVE_OSF_SIA */
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
-----------------------------------------------------------------------
Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center
Ben Lindstrom
2002-Sep-04 16:31 UTC
uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
Grep through the code for PRIVSEP() macro. Anything that requires root (adding new TTY sessions if your using ssh corp's windows client, cleaning up after TTY sessions, etc) will reclaim root privs before running. - Ben On Wed, 4 Sep 2002, Toni L. Harbaugh-Blackford wrote:> > What do we loose by not having post-auth privsep? > > What code is executed between authorization and actual setting of the > effective uid? > > On Tue, 3 Sep 2002, Chris Adams wrote: > > > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > > It appears that the integration of the sia session setup will either > > > have to be rethought or abandoned in order for privsep to work. > > > > That was the conclusion I came to a while back. I'd like to keep > > pre-auth privsep (because that works fine and does help somewhat), but I > > don't think it is possible to do post-auth privsep on Tru64, at least > > when Enhanced Security or auditing are enabled (if they aren't, I think > > you can still do "--disable-sia", although I haven't tried that in a > > long time now). > > > > I was hoping that Ben Lindstrom would prove me wrong (and I appologize > > for not ever getting around to helping - I've got all fifty-some list > > messages about Tru64 and privsep still saved, but work's been crazy, I > > only have access to a Tru64 devel box at work, and this isn't a priority > > to work with the other stuff going on). When I last looked at it in > > depth I hadn't really gotten a good handle on how privsep worked, so I > > figured I was just missing something. > > > > Where exactly *is* the privsep transition made? > > At what point does the process that eventually runs do_child() > get its uid set to the real user? Could the setup_sia() routine > be moved out of the do_child() function to an earlier phase before > the uid is changed? > > It appears that if setup_sia() were to be moved out of do_child() > that would mean that no pty would be passed to the session unless > creation of the pty were moved out also. > > But then again whether this is worth doing depends on what we loose if > we drop post-auth privsep. > > > I'd suggest the following patch against openssh-SNAP-20020826. Most of > > it is cleanup patch from a while back that I submitted too late for > > 3.4p1 and didn't resend after that I guess. The other defines > > DISABLE_FD_PASSING when SIA is enabled, which effectively turns off > > post-auth privsep. > > So if DISABLE_FD_PASSING turns privsep off, does that mean that > session_setup_sia() will be run directly by do_child(), which > at that point will be effective uid 0? > > > Note that I haven't been able to try it with the > > latest snapshot, as I'm not at my devel box and I don't have the correct > > version of autoconf installed at the moment (need the old one for some > > other stuff I've got and haven't finagled them into working together > > yet). > > > > I'll give the patch a try. > > Thanks, > Toni > > > diff -urN openssh-SNAP-20020826/auth-sia.c openssh/auth-sia.c > > --- openssh-SNAP-20020826/auth-sia.c Fri Apr 12 10:36:08 2002 > > +++ openssh/auth-sia.c Tue Sep 3 22:03:16 2002 > > @@ -45,27 +45,25 @@ > > extern int saved_argc; > > extern char **saved_argv; > > > > -extern int errno; > > - > > int > > auth_sia_password(Authctxt *authctxt, char *pass) > > { > > int ret; > > SIAENTITY *ent = NULL; > > const char *host; > > - char *user = authctxt->user; > > > > host = get_canonical_hostname(options.verify_reverse_mapping); > > > > - if (!user || !pass || pass[0] == '\0') > > + if (!authctxt->user || !pass || pass[0] == '\0') > > return(0); > > > > - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, NULL, 0, > > - NULL) != SIASUCCESS) > > + if (sia_ses_init(&ent, saved_argc, saved_argv, host, authctxt->user, > > + NULL, 0, NULL) != SIASUCCESS) > > return(0); > > > > if ((ret = sia_ses_authent(NULL, pass, ent)) != SIASUCCESS) { > > - error("Couldn't authenticate %s from %s", user, host); > > + error("Couldn't authenticate %s from %s", authctxt->user, > > + host); > > if (ret & SIASTOP) > > sia_ses_release(&ent); > > return(0); > > @@ -77,48 +75,35 @@ > > } > > > > void > > -session_setup_sia(char *user, char *tty) > > +session_setup_sia(struct passwd *pw, char *tty) > > { > > - struct passwd *pw; > > SIAENTITY *ent = NULL; > > const char *host; > > > > - host = get_canonical_hostname (options.verify_reverse_mapping); > > + host = get_canonical_hostname(options.verify_reverse_mapping); > > > > - if (sia_ses_init(&ent, saved_argc, saved_argv, host, user, tty, 0, > > - NULL) != SIASUCCESS) { > > + if (sia_ses_init(&ent, saved_argc, saved_argv, host, pw->pw_name, tty, > > + 0, NULL) != SIASUCCESS) > > fatal("sia_ses_init failed"); > > - } > > > > - if ((pw = getpwnam(user)) == NULL) { > > - sia_ses_release(&ent); > > - fatal("getpwnam: no user: %s", user); > > - } > > if (sia_make_entity_pwd(pw, ent) != SIASUCCESS) { > > sia_ses_release(&ent); > > fatal("sia_make_entity_pwd failed"); > > } > > > > ent->authtype = SIA_A_NONE; > > - if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) { > > - fatal("Couldn't establish session for %s from %s", user, > > - host); > > - } > > - > > - if (setpriority(PRIO_PROCESS, 0, 0) == -1) { > > - sia_ses_release(&ent); > > - fatal("setpriority: %s", strerror (errno)); > > - } > > + if (sia_ses_estab(sia_collect_trm, ent) != SIASUCCESS) > > + fatal("Couldn't establish session for %s from %s", > > + pw->pw_name, host); > > > > - if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) { > > - fatal("Couldn't launch session for %s from %s", user, host); > > - } > > + if (sia_ses_launch(sia_collect_trm, ent) != SIASUCCESS) > > + fatal("Couldn't launch session for %s from %s", pw->pw_name, > > + host); > > > > sia_ses_release(&ent); > > > > - if (setreuid(geteuid(), geteuid()) < 0) { > > + if (setreuid(geteuid(), geteuid()) < 0) > > fatal("setreuid: %s", strerror(errno)); > > - } > > } > > > > #endif /* HAVE_OSF_SIA */ > > diff -urN openssh-SNAP-20020826/auth-sia.h openssh/auth-sia.h > > --- openssh-SNAP-20020826/auth-sia.h Fri Apr 12 10:36:08 2002 > > +++ openssh/auth-sia.h Tue Sep 3 22:03:16 2002 > > @@ -27,6 +27,6 @@ > > #ifdef HAVE_OSF_SIA > > > > int auth_sia_password(Authctxt *authctxt, char *pass); > > -void session_setup_sia(char *user, char *tty); > > +void session_setup_sia(struct passwd *pw, char *tty); > > > > #endif /* HAVE_OSF_SIA */ > > diff -urN openssh-SNAP-20020826/configure.ac openssh/configure.ac > > --- openssh-SNAP-20020826/configure.ac Tue Aug 13 20:52:11 2002 > > +++ openssh/configure.ac Tue Sep 3 22:07:41 2002 > > @@ -314,6 +314,7 @@ > > AC_MSG_RESULT(yes) > > AC_DEFINE(HAVE_OSF_SIA) > > AC_DEFINE(DISABLE_LOGIN) > > + AC_DEFINE(DISABLE_FD_PASSING) > > LIBS="$LIBS -lsecurity -ldb -lm -laud" > > else > > AC_MSG_RESULT(no) > > diff -urN openssh-SNAP-20020826/session.c openssh/session.c > > --- openssh-SNAP-20020826/session.c Wed Jul 31 20:28:39 2002 > > +++ openssh/session.c Tue Sep 3 22:03:16 2002 > > @@ -1280,7 +1280,7 @@ > > */ > > if (!options.use_login) { > > #ifdef HAVE_OSF_SIA > > - session_setup_sia(pw->pw_name, s->ttyfd == -1 ? NULL : s->tty); > > + session_setup_sia(pw, s->ttyfd == -1 ? NULL : s->tty); > > if (!check_quietlogin(s, command)) > > do_motd(); > > #else /* HAVE_OSF_SIA */ > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > ----------------------------------------------------------------------- > Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov > AlphaServer 8400 System Administrator > SAIC/NCI Frederick Advanced Biomedical Computing Center > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >
Markus Friedl
2002-Sep-04 16:53 UTC
uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
On Wed, Sep 04, 2002 at 11:43:43AM -0400, Toni L. Harbaugh-Blackford wrote:> What do we loose by not having post-auth privsep?a lot.> > What code is executed between authorization and actual setting of the > effective uid?all the protocol parsing is still run with uid==0, only the forked login shell has the uid of the authenticated used.