> Norm,
> 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.
Talking to Nico off line about something else, he said he'd looked
some at tiocsti and felt it was a bug that you couldn't control
the tty/pty that you own. I don't find TIOCSTI adequately
documented by Sun. But google did it.
From my understanding of what it does, feeds input to a tty,
I would say privs=all is quite extreme. The secpolicy_sti()
comment says: "Simulate terminal input; another escalation of
privileges avenue"
I can see that if you're writing to a tty that you don't own.
But if you own it, IMO this shouldn't be the policy and it is
a bug. IMO, the correct architectural thing to do here is
to fix the bug. I'd guess the policy to be, if you have write
access to the tty, you should be able to issue a TIOCSTI.
And to stop privilege escalation, the if owned by uid 0 policy
also comes into play (file_dac_write is insufficient, privs=all
is required).
IMO, this case should be withdrawn and the bug should be fixed.
If I'm wrong about the bug, then the case should be reintroduced
with rational as to why there isn't a bug and what the policy really
should be for TIOCSTI.
I'll give the project team a while to answer this before considering
further steps, such as withdrawn, waiting need spec or even derail
for a meeting.
Trying to stomp out bugs (that lead to unnecssary privileges),
Gary..
