Re: [zones-discuss] zlogin and locales

2008-04-02 Thread Vincent Boisard
Thanks,

Vincent
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zlogin and locales

2008-04-02 Thread Moore, Joe
Steve Lawrence wrote:
 Looks like the environment contained in /etc/default/init is 
 read and set
 by startd and init.  Since zlogin'ed processes are not child 
 of startd or init
 in the zone, they do not have these environment settings.
 
 Given brands, to fix this, we would need to add a hook that 
 asks the zone:
 
 Please fetch me the default login environment.

And hope that the zone adminstrator hasn't figured out a way to violate
security constraints by setting malicious variables in that default
login environment...

Such as a specially-corrupted termcap (pushing data to the global-zone
xterm, for example), or a locale with similar features

 
 It would be similar to the hook that we currently have for 
 fetching the
 passwd entry for a given user.

passwd entries are fairly easy to validate.  Arbitrary environment
variables should not be accepted from an untrusted source.

--Joe
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zlogin and locales

2008-04-02 Thread Steve Lawrence
On Wed, Apr 02, 2008 at 11:11:12AM -0400, Moore, Joe wrote:
 Steve Lawrence wrote:
  Looks like the environment contained in /etc/default/init is 
  read and set
  by startd and init.  Since zlogin'ed processes are not child 
  of startd or init
  in the zone, they do not have these environment settings.
  
  Given brands, to fix this, we would need to add a hook that 
  asks the zone:
  
  Please fetch me the default login environment.
 
 And hope that the zone adminstrator hasn't figured out a way to violate
 security constraints by setting malicious variables in that default
 login environment...

You mean fetch the environment, but don't set for the zlogin process in
the global zone.  Just pass it into the zone and set it when exec'ing
the login process.

 
 Such as a specially-corrupted termcap (pushing data to the global-zone
 xterm, for example), or a locale with similar features
 
  
  It would be similar to the hook that we currently have for 
  fetching the
  passwd entry for a given user.
 
 passwd entries are fairly easy to validate.  Arbitrary environment
 variables should not be accepted from an untrusted source.
 
 --Joe
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org