Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]

[Gary Winiger]

> 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..