(pag) AW: Re: [OpenAFS] Redux: Linux: systemctl --user vs. AFS
R.Laatsch
Rainer.Laatsch@t-online.de
Fri, 6 Aug 2021 01:46:26 +0200 (CEST)
------=_Part_7109544_693973205.1628207187051
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Usually i geht rid of a pag with
keyctl new_session
Might possibly work for you.
To (re)start Prozesses, i am using "at",
e.g.
echo /usr/sbin/sshd | at now
Regards, Rainer
------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_send=
mail_footer>
--- Original-Nachricht ---
Von: Stephen
Betreff: Re: [OpenAFS] Redux: Linux: systemctl --user vs. AFS
Datum: 05. August 2021, 18:32
An: spacefrogg-openafs@spacefrogg.net
Cc: openafs-info@openafs.org
Michael,
Thanks for the reply.
On Thu, 5 Aug 2021, spacefrogg-openafs@spacefrogg.net
<mailto:spacefrogg-openafs@spacefrogg.net> wrote:
> While this thread is live again, let me contribute my own findings on
> this. Our network runs mainly NixOS machines.
>
> For us, using sssd for Kerberos ticket management turned out to be a huge
> benefit, mainly for its centralized ticket refresh functionality. We hold
> users' tickets in well-known files. Using sssd lifts the necessity to
> have the directory holding ticket caches user-writable. So, well-known
> cache files is not a security concern anymore.
>
> We use systemd, as well. We have set up the systemd-user@.service
<mailto:systemd-user@.service> in a
> way, that it acquires an AFS token before starting. Thus, all dependent
> user services have AFS access. This is what we need well-known ticket
> cache files for. PAM has already run at the time, so the cache is hot.
That approach sounds interesting. Are the specifics documented anywhere for
someone wanting to replicate and evaluate it?
> Lingering does obviously not work with this setup.
>
> We use nopag tokens, as we don't believe in its added security promises.
> In parallel, we allow ticket forwarding for remote logins, mainly for the
> benefit of single sign-on. So, this circumvents most promises, PAGs would
> give us anyway.
>
> nopag also allows us to post-acquire AFS token for systemd services of a
> running session, which is important for road-warrior (does one still use
> this term?) setups.
>
> PAGs are a big usability bonus, though, when using pagsh to temporarily
> acquire an administrative shell.
I have also enjoyed this functionality historically. My worry though is if
you use nopag everywhere, but then use pags for admin tasks, what happens
if you accidentally start a shared process (sshd, etc) from an admin PAG
when you and/or the process are assuming tokens are per-uid, rather than
per-pag?
To the best of my knowledge, there's no way for a process to drop a PAG
once it is started within one and once you're in a PAG, tokens are then
per-pag and not per-uid. That's why I took the hybrid approach where ssh's
pam still creates PAGs on login (basically all of my admin occurs via ssh
either manually or via ansible).
Someone please correct me if my assumptions or understanding are wrong!
> Hope this helps!
>
> =E2=80=93Michael
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org <mailto:OpenAFS-info@openafs.org>
><https://lists.openafs.org/mailman/listinfo/openafs-info>
------=_Part_7109544_693973205.1628207187051
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Usually i geht rid of a pag with<br/> keyctl new_session<br/>Might possib=
ly work for you.<br/>To (re)start Prozesses, i am using "at",<br/>e.g.<br/>=
echo /usr/sbin/sshd | at now<br/> <br/>Regards, Rainer<br/><br/><br/><hr>=
</hr>Gesendet mit der <a href=3D"https://kommunikationsdienste.t-online.de/=
redirects/email_app_android_sendmail_footer">Telekom Mail App</a><br> <br><=
br/><br/>--- Original-Nachricht ---<br/><b>Von: </b>Stephen<br/><b>Betreff=
: </b>Re: [OpenAFS] Redux: Linux: systemctl --user vs. AFS<br/><b>Datum: =
</b>05. August 2021, 18:32 <br/><b>An: </b>spacefrogg-openafs@spacefrogg.n=
et<br/><b>Cc: </b>openafs-info@openafs.org<br/><br/><br/><br> <br><html><h=
ead> <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-sc=
ale=3D1.0" /> <style type=3D"text/css">@font-face {=09font-family: teleg=
rotesk-medium_normal;=09src: url("file:///android_asset/fonts/telegrotesk_n=
ormal.ttf");}html,body {=09font-family: "telegrotesk-medium_normal";=09font=
-size: medium;=09color: #4b4b4b;=09width: 100%;}</style></head><body><div> =
Michael,<br/><br/>Thanks for the reply.<br/><br/>On Thu, 5 Aug 2021, <a =
href=3D"mailto:spacefrogg-openafs@spacefrogg.net">spacefrogg-openafs@spacef=
rogg.net</a> wrote:<br/><br/>> While this thread is live again, let me c=
ontribute my own findings on <br/>> this. Our network runs mainly NixOS =
machines.<br/>><br/>> For us, using sssd for Kerberos ticket manageme=
nt turned out to be a huge <br/>> benefit, mainly for its centralized ti=
cket refresh functionality. We hold <br/>> users' tickets in well-kn=
own files. Using sssd lifts the necessity to <br/>> have the directory h=
olding ticket caches user-writable. So, well-known <br/>> cache files is=
not a security concern anymore.<br/>><br/>> We use systemd, as well.=
We have set up the <a href=3D"mailto:systemd-user@.service">systemd-user@.=
service</a> in a <br/>> way, that it acquires an AFS token before starti=
ng. Thus, all dependent <br/>> user services have AFS access. This is wh=
at we need well-known ticket <br/>> cache files for. PAM has already run=
at the time, so the cache is hot.<br/><br/>That approach sounds interestin=
g. Are the specifics documented anywhere for <br/>someone wanting to replic=
ate and evaluate it?<br/><br/>> Lingering does obviously not work with t=
his setup.<br/>><br/>> We use nopag tokens, as we don't believe i=
n its added security promises. <br/>> In parallel, we allow ticket forwa=
rding for remote logins, mainly for the <br/>> benefit of single sign-on=
. So, this circumvents most promises, PAGs would <br/>> give us anyway.<=
br/>><br/>> nopag also allows us to post-acquire AFS token for system=
d services of a <br/>> running session, which is important for road-warr=
ior (does one still use <br/>> this term?) setups.<br/>><br/>> PAG=
s are a big usability bonus, though, when using pagsh to temporarily <br/>&=
gt; acquire an administrative shell.<br/><br/>I have also enjoyed this func=
tionality historically. My worry though is if <br/>you use nopag everywhere=
, but then use pags for admin tasks, what happens <br/>if you accidentally =
start a shared process (sshd, etc) from an admin PAG <br/>when you and/or t=
he process are assuming tokens are per-uid, rather than <br/>per-pag?<br/><=
br/>To the best of my knowledge, there's no way for a process to drop a=
PAG <br/>once it is started within one and once you're in a PAG, token=
s are then <br/>per-pag and not per-uid. That's why I took the hybrid a=
pproach where ssh's <br/>pam still creates PAGs on login (basically all=
of my admin occurs via ssh <br/>either manually or via ansible).<br/><br/>=
Someone please correct me if my assumptions or understanding are wrong!<br/=
><br/>> Hope this helps!<br/>><br/>> =E2=80=93Michael<br/>> ___=
____________________________________________<br/>> OpenAFS-info mailing =
list<br/>> <a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@open=
afs.org</a><br/>> <a href=3D"https://lists.openafs.org/mailman/listinfo/=
openafs-info" target=3D"_top" >https://lists.openafs.org/mailman/listinfo/o=
penafs-info</a></div></body></html>
------=_Part_7109544_693973205.1628207187051--