Roland Mainz writes:
> James Carlson wrote:
> [snip]
> > > maybe for now pf should trump all builtins but the ones already allowed
> > > whether by /usr/ast/bin or not
> >
> > That'd be the least problematic answer.
>
> But IMO it is the wrong solution (see my other emails for details, the
> builtin thing is something coming from the POSIX shell specs).
As long as ignoring it for things that exist in the real file system
does not cause functional differences that the user can see (beyond
perhaps performance), I fail to see how this matters.
> > > is this a restriction issue? is a user knowingly executing an explicit
> > > builtin
> > > a violation (as in a restricted shell sense)?
> >
> > It could be. RBAC does have the ability to revoke privileges.
>
> Uhm... could you describe an example ? AFAIK RBAC only grants extended
> priviledges via the RBAC context but it cannot remove them if they are
> part of what a plain, normal user can do (because he/she could simply
> run a normal shell and/or switch the shell to the normal, non-profile
> shell mode, bypassing the execution within a RBAC context)... or not ?
Darren has already answered this in a separate message. You can set
limitprivs= to yank away privileges that you don't want the user to
have for a given executable, as well as change the {e,}[ug]id on the
process that runs.
Whether this is 'effective' is perhaps another matter, as it doesn't
cover other applications that might issue the same system calls, but
it's certainly a supported feature.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
