[desktop-discuss] [security-discuss] requirement for identifying a console user in RBAC

[Jason King]

On 8/16/07, Riny Qian <Riny.Qian at sun.com> wrote:
> I think the purpose here is to provide the console user with some
> authorizations/privileges so that he/she can run some admin tools
> (e.g. gnome-sys-suspend, g-p-m, poweroff) successfully. Then there
> are at least two questions to be answered:
>
> 1. Which admin tools should be provided to the console use? so that
>     which authorizations/privileges should be assigned to the console
>     user?
>
> 2. How to dynamically assign authorizations/privileges to the console
>     user?
>
> For the second question, we may add supporting library functions (e.g.
> console_role_login/console_role_logout, just like di_devperm_login/
> di_devperm_logout for console devices permission) for login programs
> (login, dtlogin, gdm) to dynamically assign required authorizations/
> privileges for the logged in console user upon login/logout.  Maybe
> there are better ideas.
>
> Another way to think about this purpose is that probably we can
> add a supporting library function like is_console_user() for admin tools
> which are identified to be used by the console user. Then these
> admin tools may need to be turned into suid root programs or something
> like that. This way requires the change to all admin tools, so it
> doesn't look good.
>
> Regards,
> Riny
>
> Lin Ma wrote:
> > Hi,
> >
> > Currently we can see there are lots of requirements in system user-level
> > for identifying a console user especially in the scope of admin tools,
> > e.g. gnome-sys-suspend, gpm, nwam, etc. I think those tools would like
> > to give console user the priviledge to use them. I know now we have to
> > check the owner of /dev/console to identify in each application if
> > necessary. But to be Solaris RBAC compliable, we'd better to use an
> > auth_attr like solaris.device.console[.session] or whatever.
> >
> > So I think the best way is to hack login application (dtlogin, gdm,
> > ttymon, etc). I've talked with Riny, he think all the login applications
> > finally invoke console_role_log[in|out] to change the owner of
> > /dev/console. If so, I think we can change those function to add the
> > auth which I mentioned above to the login user. Riny told me if we have
> > the requirement, we can set up a discussion to change those functions
> > since they (Riny and his team) own them.
> >
> > But here're some tech issues. Since all the changes happen in user
> > land. So I take a quick look of /usr/man/man3secdb (note I'm not good at
> > SEC), I found there are no functions supporting temporary change the
> > auths of a user. But in one of them mentioned libsecdb has an internal
> > storage (I guess I can say it cache) of sec related information for a
> > user. Since permanently changing /etc/user_attr for a console user is
> > not a good idea, so maybe we need assistance of security team to evolve
> > them.
> >
> > (We may make things complicate if we like. e.g. append a special
> > role to a console user)
> >
> > Is it possible? Comments?
> >
> > lin
> >
>
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>

Wouldn't some of the work in the reno project facilitate some/all of this??

http://www.opensolaris.org/os/project/reno/brief/  Section 5.3 sounds
like that might include adding authorizations to users logging into
the console?