[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    Re: [security-discuss] requirement for identifying a console user
From:       Lin Ma <Lin.Ma () Sun ! COM>
Date:       2007-08-18 7:21:33
Message-ID: 46C69DFD.1000203 () Sun ! COM
[Download RAW message or body]

I guess you aim to eliminate the "console user" concept, however it's 
also a good way to applications, then maybe we can remove 
logindevperm(4) or at least upgrade it to auth/priviledge mode. But I'm 
curious of a very low priviledge user's feeling when he is refused to 
plug in his USB disk or he can't use it :-)

If remove the "console user", so we have to identify the different 
profiles due to the different users, e.g. laptop user profile. But 
currently there's only "Basic Solaris User" in Solaris. If we define a 
laptop user profile which has the auth/priviledge which allow the user 
poweroff/connect network, then the default profile (when adding a user 
w/o specify any profiles) "Basic Solaris User" will not be allowed to 
use network or poweroff. So what the user can do is to "su root/role"?

To come up with other OS we need Solaris install (Caiman?) to detect the 
install scenario like laptop/desktop/server, etc and create non-root 
accounts. Does Caiman support install scenario?

Darren J Moffat wrote:
> I'm quite nervous about assigning any additional authorisations to a 
> user based on which tty their login program happened to run on.  My 
> main concern is that there are deployment cases where this is a good 
> default and ones where it is a bad default.
>
> For all of the use cases sited I think these would be easily covered 
> by creating a new RBAC profile and assigning that to the user not at 
> login (because profiles don't work that way) but permenantly on that 
> machine.
>
> I can see two cases where this functionality is useful:
>
> 1) Laptop - especially for networking
> 2) Personal desktop.
>
> In case 1 you want to give users the ability to do a limited set of 
> system configuration/admin but you don't want them to have the full 
> control over the machine.  This is how Windows laptops are often 
> deployed in a corporate environment.
>
> Cases where you don't want users to get additional authorisations just 
> because they logged in on the console include:
>
> 1) Corporate desktop - non Sun Ray
> 2) Student lab
>
> I believe that the functionality being requested is really a property 
> of the *user* not where and how they logged in.
>
> Maybe what we really need here is to ask and assign this "owner" 
> profile when the first non root user is created during install.  This 
> is, if I remember correctly, what MacOS X and Windows XP basically do.
>
>
> Now back to the general case, being able to have different RBAC 
> profiles based on "where" you are is actually a very useful concept - 
> I have code  that uses the "qualifier" field in user_attr(4) to limit 
> when an user gets a profile based on host or netgroup. [ Not 
> integrated because it requires updating the SMC user tool and I don't 
> know how to do that ].
>
> -- 
> Darren J Moffat

-- 
x82120 / +86 10 82618200

_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]