Norm,
Sorry I didn't number my questions. I agree a Rights Profile
is far more in keeping with minimizing the attack surface of
programs than making them suid. Any how:
1) To whom is the "Parallel Console Access" Rights Profile granted?
2) How is the "Parallel Console Access" Rights Profile granted to
users?
What I'm trying to get at here is: Is Parallel Console Access
automatically granted and if so to whom?
3) A help file needs to be part of creating this Rights Profile.
See:
http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
4) Conclusion on privs/uids.
Nit: the exec_attr entry s/suser/solaris/
Is it really the euid that matters, or is it that euid=0 gives
privs=all? I don't know how to answer the tiocsti question.
I'm not sure that's this case (though it would be nice if
the policy was revisited and this case dependent on that revisit),
but I'm not suggesting that be the a case requirement.
Perhaps an offline email if I've not been clear.
Thankx,
Gary..
> Gary Winiger wrote:
> >> /etc/security/prof_attr:
> >> Parallel Console Access:::Connect to remote consoles with pconsole:
> >>
> >
> > To whom/how is this Rights Profile granted?
> >
> > Also note that a help file needs to come with the addition of
> > a Rights Profile. See:
> > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
> >
> >
> >> /etc/security/exec_attr:
> >> Parallel Console Access:suser:cmd:::/usr/sbin/pconsole-bin:euid=0
> >>
> >
> > I've not seen a conclusion on privileges/uids.
> >
> It appears that unless the policy around TIOCSTI changes to allow the
> device owner to use it, then pconsole-bin needs to run with euid=0 to be
> useful. It seemed like creating a rights profile for this and allowing
> assignment of that rights profile to a select set of users made more
> sense than making pconsole-bin suid root. With a rights profile, our
> customers can control access to it by assigning this profile to users
> that have a need for pconsole. With it suid root, anyone can use it and
> potentially use it to effectively hijack someone else's session. With
> no rights profile and no suid root, you have to become root to use it.
>
> As for who is most likely to use it and therefore need access to the
> profile, I expect, based on the original case, it will be sysadmins
> managing clusters.
>
> -Norm
>
