Sun Ray Server Software and the Sun Ray Ultra-Thin Hardware Clients ()

Joerg Barfurth | 2 Feb 2009 12:39

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

You can do much of what you desire by editing /etc/pam.conf. But the 
result is an unsupported configuration.

David Markey schrieb:
> They could manually detach the session using shift+pause, its just 
> complicated for our users and id like to disable it. i see its hard 
> coded into xscreensaver. Any way to disable it even unsupported?
> 

You could remove or turn into a comment the
   xscreensaver auth sufficient pam_sunray.so syncondisplay
line in /etc/pam.conf.

The price you have to pay for that is that when hotdesking to a 
different DTU with your NSCM session or after the session has been 
detached in whatever other way (e.g. by rebooting the DTU), you'll have 
to enter your password twice - first for NSCM, then for the screensaver.

You also lower security for your session, as explained by Bob.

> Also, when i do a utswitch -h <hostname> the previous user name gets 
> entered into the new sunray servers login, any way to disable that also?
> 

For NSCM users: To get rid of the name you can use the startover button. 
To never get that name in the first place, you could try to remove the
    utgulogin auth requisite sunray_get_user.so  property=username
line in /etc/pam.conf.

To achieve the same effect for smartcard users, you'd need to also

(Continue reading)

William Yang | 2 Feb 2009 16:29

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

Regarding RHA security...

Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS setup?
We seem to be stuck with forcing users to unlock twice since unfortunately
we need the screensaver to refresh a user's tickets and tokens.  Since the
RHA dialog creates a temporary session, the tickets and tokens for the
user's session aren't refreshed when it is used, so for the time being we
use RHA and screensaver lock to achieve better security and still maintain
the ability to refresh session creds.  Any ideas?

William Yang

> -----Original Message-----
> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
> bounces <at> filibeto.org] On Behalf Of Joerg Barfurth
> Sent: Monday, February 02, 2009 6:39 AM
> To: SunRay-Users mailing list
> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
> and not utdetach with NSCM
> 
> You can do much of what you desire by editing /etc/pam.conf. But the
> result is an unsupported configuration.
> 
> David Markey schrieb:
> > They could manually detach the session using shift+pause, its just
> > complicated for our users and id like to disable it. i see its hard
> > coded into xscreensaver. Any way to disable it even unsupported?
> >
> 
> You could remove or turn into a comment the

(Continue reading)

Bob Doolittle | 2 Feb 2009 17:12

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

William Yang wrote:
> Regarding RHA security...
>
> Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS setup?
> We seem to be stuck with forcing users to unlock twice since unfortunately
> we need the screensaver to refresh a user's tickets and tokens.  Since the
> RHA dialog creates a temporary session, the tickets and tokens for the
> user's session aren't refreshed when it is used, so for the time being we
> use RHA and screensaver lock to achieve better security and still maintain
> the ability to refresh session creds.  Any ideas?
>   

What version of SRSS?

What OS platform are you using? If it's Linux, then we may have an issue 
here since gnome-screensaver doesn't handle PAM properly so we can't 
utilize pam_sunray (which refreshes creds on the screensaver stack) and 
use utxunlock instead.  utxunlock has no way of directly refreshing creds.

-Bob

> William Yang
>
>   
>> -----Original Message-----
>> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
>> bounces <at> filibeto.org] On Behalf Of Joerg Barfurth
>> Sent: Monday, February 02, 2009 6:39 AM
>> To: SunRay-Users mailing list
>> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen

(Continue reading)

William Yang | 2 Feb 2009 22:57

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

4.1 on S10U6.  I don't know if this is possible because of the way AFS does
PAGs.

William Yang

> -----Original Message-----
> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
> bounces <at> filibeto.org] On Behalf Of Bob Doolittle
> Sent: Monday, February 02, 2009 11:12 AM
> To: SunRay-Users mailing list
> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
> and not utdetach with NSCM
> 
> William Yang wrote:
> > Regarding RHA security...
> >
> > Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS
> setup?
> > We seem to be stuck with forcing users to unlock twice since
> unfortunately
> > we need the screensaver to refresh a user's tickets and tokens.  Since
> the
> > RHA dialog creates a temporary session, the tickets and tokens for the
> > user's session aren't refreshed when it is used, so for the time being
> we
> > use RHA and screensaver lock to achieve better security and still
> maintain
> > the ability to refresh session creds.  Any ideas?
> >
>

(Continue reading)

Bob Doolittle | 2 Feb 2009 23:46

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

William Yang wrote:
> 4.1 on S10U6.  I don't know if this is possible because of the way AFS does
> PAGs.
>   

And pam_sunray is on the xscreensaver (or dtsession-Sunray if CDE) stack 
in /etc/pam.conf?

I'm afraid I don't know anything about AFS and we don't support it :(

-Bob

> William Yang
>
>   
>> -----Original Message-----
>> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
>> bounces <at> filibeto.org] On Behalf Of Bob Doolittle
>> Sent: Monday, February 02, 2009 11:12 AM
>> To: SunRay-Users mailing list
>> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
>> and not utdetach with NSCM
>>
>> William Yang wrote:
>>     
>>> Regarding RHA security...
>>>
>>> Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS
>>>       
>> setup?

(Continue reading)

William Yang | 12 Feb 2009 23:57

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

Yes.  But, we use our own compiled xscreensaver since the Sun-shipped one
had issues interacting with the pam_krb5 we use (slightly patched version of
Russ Allbery's pam-krb5).  So RHA is not triggered by the screensaver,
although it is still invoked on a smart card hotdesk event.

So I know our setup isn't supported, but I can come up with a theoretically
supported situation which should be equivalently impacted:
Site uses NFSv4 with Kerberos for home directories.  User's tickets expire
while detached, RHA does not refresh tickets on attaching, and user has lost
access to home directory (the same thing basically happens with our AFS
setup).

The same resolution for that setup should be applicable to our AFS setup.
Any ideas?

Thanks,
William Yang

> -----Original Message-----
> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
> bounces <at> filibeto.org] On Behalf Of Bob Doolittle
> Sent: Monday, February 02, 2009 5:46 PM
> To: SunRay-Users mailing list
> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
> and not utdetach with NSCM
> 
> William Yang wrote:
> > 4.1 on S10U6.  I don't know if this is possible because of the way AFS
> does
> > PAGs.

(Continue reading)

Joerg Barfurth | 13 Feb 2009 00:55

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

William Yang schrieb:
> Yes.  But, we use our own compiled xscreensaver since the Sun-shipped one
> had issues interacting with the pam_krb5 we use (slightly patched version of
> Russ Allbery's pam-krb5).  So RHA is not triggered by the screensaver,
> although it is still invoked on a smart card hotdesk event.
> 
> So I know our setup isn't supported, but I can come up with a theoretically
> supported situation which should be equivalently impacted:
> Site uses NFSv4 with Kerberos for home directories.  User's tickets expire
> while detached, RHA does not refresh tickets on attaching, and user has lost
> access to home directory (the same thing basically happens with our AFS
> setup).
> 
> The same resolution for that setup should be applicable to our AFS setup.
> Any ideas?
> 

Part of a correct resolution would probably be for the RHA loginGUI to 
call pam_setcred with the PAM_REFRESH_CRED flag instead of 
PAM_ESTABLISH_CRED, as it currently does. I just discovered that it 
doesn't do this, which is a clear bug.

This should cover all cases where credentials are stored in the user's 
home directory and are not bound to a specific X display. So this should 
apply to the kerberos credentials cache.

How does AFS store/cache its credentials?

- Jörg

(Continue reading)

William Yang | 13 Feb 2009 01:19

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

> This should cover all cases where credentials are stored in the user's
> home directory and are not bound to a specific X display. So this should
> apply to the kerberos credentials cache.

This probably still won't work in our case since RHA is not going to pick up
the correct ccache file from an environment variable.  The screensaver does
since it is part of the same environment.

> How does AFS store/cache its credentials?

It uses PAGs, which based on my limited understanding, are a form of
pseudo-environment where all processes included in it have access to the
same set of AFS tokens.  That is, AFS tokens are managed in-kernel, as
opposed to Kerberos tickets which are currently managed by storing in a file
in /tmp and setting the KRB5CCNAME env var.  Hence, a token refresh would
need to be triggered from something already inside the PAG.

William Yang

Bob Doolittle | 13 Feb 2009 00:46

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

William Yang wrote:
> Yes.  But, we use our own compiled xscreensaver since the Sun-shipped one
> had issues interacting with the pam_krb5 we use (slightly patched version of
> Russ Allbery's pam-krb5).  So RHA is not triggered by the screensaver,
> although it is still invoked on a smart card hotdesk event.
>   

If you use pam_sunray.so on your PAM stack, then RHA should still be 
triggered.
We didn't modify xscreensaver for SRSS.

> So I know our setup isn't supported, but I can come up with a theoretically
> supported situation which should be equivalently impacted:
> Site uses NFSv4 with Kerberos for home directories.  User's tickets expire
> while detached, RHA does not refresh tickets on attaching, and user has lost
> access to home directory (the same thing basically happens with our AFS
> setup).
>   

If you have pam_sunray.so on your xscreensaver stack, then everything 
should work. But the screensaver has to be well behaved in a few ways:
- It must not require a user interaction (i.e. it must not assume that 
conversation function will ever be called)
- It must call pam_authenticate immediately upon session lock, and not 
wait for events like mouse movement or keyboard events first

The model is that even though authentication occurs outside of the 
session with RHA, we still run the PAM stack for the screensaver when 
the desktop session is connected. It's at that time that tickets should 
be refreshed. pam_sunray bypasses the authentication interaction with

(Continue reading)

William Yang | 13 Feb 2009 01:14

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

But wouldn't that only work using the traditional Solaris pam_krb5 model
(which is to use the same cred cache for every session as long as it's the
same user)?  The problem is that RHA processes the password verification in
the uthotdesk stack, using a temporary session, and in our case a temporary
ccache that gets thrown out later.  When that stack exits, it kicks back up
to the xscreensaver stack, where it sees that the RHA unlock was successful
and exits the PAM stack since it is "sufficient" for pam_sunray.so.  The
successive pam_setcreds may get called, but pam_krb5.so can't renew the
creds without the user's password.  Even if the password were passed back
up, I think this pam_krb5 by design will not attempt to setcred if it was
not the module that successfully authenticated the user.  Please correct me
if I'm not tracing the PAM stack properly.

I'm not sure why our screensaver isn't triggering the RHA dialog at all...I
know the stock xscreensaver doesn't call the stack as soon as you lock, that
was a patch worked into the Sun xscreensaver.  But even when the screensaver
dialog is triggered, the RHA dialog still doesn't come up, but for our
purposes that is okay.

Can someone out there verify that RHA is able to refresh their Kerberos
tickets if they are per-session?  Or is that something I will need to file
an RFE for, especially since right now the pam_krb5 included in Solaris
doesn't support per-session ccaches?

William Yang

> -----Original Message-----
> From: sunray-users-bounces <at> filibeto.org [mailto:sunray-users-
> bounces <at> filibeto.org] On Behalf Of Bob Doolittle
> Sent: Thursday, February 12, 2009 6:46 PM

(Continue reading)

Bob Doolittle | 13 Feb 2009 21:21

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

Unfortunately, this seems to be a chicken-and-egg issue. In the extreme 
case, we can't authenticate you in a separate session if the PAM 
authentication modules have tight, unconstrained dependencies on the 
session context itself. We could do a couple of things in this area to 
get closer, but the general case seems unsolvable. Luckily, few PAM 
modules have such tight constraints, and thus almost all work fine with RHA.

At the moment, it doesn't seem we have any recourse for you other than 
to disable RHA with the -D policy option.

Your answer to Joerg's question regarding AFS's store/cache method for 
creds may help guide us to a better long-term solution for your PAM 
model. Do you use pam_putenv()?

-Bob

William Yang wrote:
> But wouldn't that only work using the traditional Solaris pam_krb5 model
> (which is to use the same cred cache for every session as long as it's the
> same user)?  The problem is that RHA processes the password verification in
> the uthotdesk stack, using a temporary session, and in our case a temporary
> ccache that gets thrown out later.  When that stack exits, it kicks back up
> to the xscreensaver stack, where it sees that the RHA unlock was successful
> and exits the PAM stack since it is "sufficient" for pam_sunray.so.  The
> successive pam_setcreds may get called, but pam_krb5.so can't renew the
> creds without the user's password.  Even if the password were passed back
> up, I think this pam_krb5 by design will not attempt to setcred if it was
> not the module that successfully authenticated the user.  Please correct me
> if I'm not tracing the PAM stack properly.
>

(Continue reading)

William Yang | 14 Feb 2009 03:18

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

> Unfortunately, this seems to be a chicken-and-egg issue. In the extreme
> case, we can't authenticate you in a separate session if the PAM
> authentication modules have tight, unconstrained dependencies on the
> session context itself. We could do a couple of things in this area to
> get closer, but the general case seems unsolvable. Luckily, few PAM
> modules have such tight constraints, and thus almost all work fine with
> RHA.

Security vs. security :/

> At the moment, it doesn't seem we have any recourse for you other than
> to disable RHA with the -D policy option.

We do like RHA for its security, so right now we just let users
double-unlock.  (We don't have smart card users right now.)

> Your answer to Joerg's question regarding AFS's store/cache method for
> creds may help guide us to a better long-term solution for your PAM
> model. Do you use pam_putenv()?

I believe the pam_krb5 does do pam_putenv to set the KRB5CCNAME variable.
Source is available here: http://www.eyrie.org/~eagle/software/pam-krb5/

Does pam_sunray.so set the password in PAM_AUTHTOK like pam_authtok_get
otherwise would?  If it does, we may be able to work something out where the
xscreensaver stack looked like this instead:
xscreensaver auth required /opt/SUNWut/lib/pam_sunray.so syncondisplay
xscreensaver auth requisite pam_authtok_get.so.1
xscreensaver auth required pam_unix_cred.so.1 nowarn
xscreensaver auth sufficient /usr/local/lib/security/pam_krb5.so use_authtok

(Continue reading)

Joerg Barfurth | 15 Feb 2009 19:37

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

William Yang schrieb:
>> Unfortunately, this seems to be a chicken-and-egg issue. In the extreme
>> case, we can't authenticate you in a separate session if the PAM
>> authentication modules have tight, unconstrained dependencies on the
>> session context itself. We could do a couple of things in this area to
>> get closer, but the general case seems unsolvable. Luckily, few PAM
>> modules have such tight constraints, and thus almost all work fine with
>> RHA.
> 
> Security vs. security :/
> 

:-/

>> Your answer to Joerg's question regarding AFS's store/cache method for
>> creds may help guide us to a better long-term solution for your PAM
>> model. Do you use pam_putenv()?
> 

I actually had the impression that AFS uses somethign else that we can't 
easily address.

> I believe the pam_krb5 does do pam_putenv to set the KRB5CCNAME variable.
> Source is available here: http://www.eyrie.org/~eagle/software/pam-krb5/
> 

I thought so. Proper support for variables from pam_putenv in NSCM and 
RHA is something that is still lacking, but should be doable.

> Does pam_sunray.so set the password in PAM_AUTHTOK like pam_authtok_get

(Continue reading)

Detlev Habicht | 16 Feb 2009 10:12

Picon

Picon

Split Screen with Sun Ray 2FS

Hi all,

we know, it is sometimes not nice to use 2 monitors on a Sun Ray 2FS,  
because
we have only one big screen and it is not possible to split the screen
in relationship to the monitors.

There are some tools available for Windows, e.g. splitscreen.

We found now "Fake Xinerama". (http://ktown.kde.org/~seli/fakexinerama/)

It is working fine with Linux.

But we can't use it on Solaris.

Is here someone, who use it on Solaris? How to configure it?

Detlev

--
   Detlev  | Institut fuer Mikroelektronische Systeme
   Habicht | D-30167 Hannover +49 511 76219662  
habicht <at> ims.unihannover.de
   --------+-------- Handy    +49 172 5415752   
---------------------------

William Yang | 15 Feb 2009 19:55

RE: How to make JDS lock screen lock the screen and not utdetach with NSCM

> >> Your answer to Joerg's question regarding AFS's store/cache method for
> >> creds may help guide us to a better long-term solution for your PAM
> >> model. Do you use pam_putenv()?
> >
> 
> I actually had the impression that AFS uses somethign else that we can't
> easily address.

That's right.  AFS does not depend on environment variables.  Tokens need to
be refreshed inside the same PAG, somehow.

> > I believe the pam_krb5 does do pam_putenv to set the KRB5CCNAME
variable.
> > Source is available here: http://www.eyrie.org/~eagle/software/pam-krb5/
> >
> 
> I thought so. Proper support for variables from pam_putenv in NSCM and
> RHA is something that is still lacking, but should be doable.

I'm not sure how this would help here, since wouldn't RHA just write to a
different ccache than the one in use by the environment?

> > Does pam_sunray.so set the password in PAM_AUTHTOK like pam_authtok_get
> > otherwise would?
> 
> No it does not. It maintains authentication state, but keeping the
> cleartext password around to pass into the other session doesn't seem
> such a good idea.

It could be a non-default PAM option like "pass_authtok" with a documented

(Continue reading)

Bob Doolittle | 13 Feb 2009 00:52

Picon

Re: How to make JDS lock screen lock the screen and not utdetach with NSCM

Bob Doolittle wrote:
> pam_sunray bypasses the authentication interaction with the user, but 
> the PAM authentication stacks are still processed, including 
> pam_sm_authenticate and pam_sm_setcred(PAM_REFRESH)

Sorry, that should be PAM_REFRESH_CRED, of course.

-Bob

Return

Return to gmane.os.solaris.sunray.

Advertisement

Project Web Page

Sun Ray Server Software and the Sun Ray Ultra-Thin Hardware Clients ()

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane