# $Id: README,v 1.5 2010/09/15 15:41:45 ksb Exp $

These are the jacket spells I've coded.

ttyowner - Prevent some chained escalations, we check the owner of the
	controlling tty (stdin, stderr, or stdout in order) against a
	parameter ($TTYOWNER).  If you op to "bob" and try to run a rule
	that is protected with this spell and "$TTYOWNER=bob" then the
	access will be refused.  If you can trick "script" into running
	(or xterm) you may be able to prevent this check from stopping you,
	but it will stop someone in a restricted shell.  It is a pretty fair
	eample of a dual purpose helmet/jacket.

timestamp - Allow additional escalations in a fixed time window based
	on a stamp file (kinda).  The "file" is actually a local domain
	socket that actively answers requests for access, it has a timeout
	and some other things it reads from the op environment.

	This can also be used to allow two-factor authentication: by
	allowing 1 access to set the jacket, and another that must see the
	jacket, but can't actually authenticate it.  This version of
	two-factor requires the first one to go first (the other version
	allows either to start the common escalation).

	Note that (by default) the timestamp per-user process can be
	accessed by the owner, and they can stop it, force it to deny
	access or reset the timer (since they could do that anyway, by
	typing their creds wrong, or such).  This allows a long running
	task to re-up the timestamp without a meaninless escalation like
	"op date"  [Viz. echo \? |nc -U /var/op/timestamps/$(id -u) ]

envauth - Allow escalations based on a timestamp or environment variable.
	Usually a timestamp pushes (via TIMESTAMP_ENVADD) a variable
	into the environment that acts as a credential for another
	escalation, which may make a two-key authentication (if it takes
	two people to do it).

signed - Don't run a rule unless the exec target has a known signature.
	If you can change the rule-base then you could change the jacket
	list to not include us, but if you can only update the target
	script you might have to get re-signed to allow changes to it.
	This is what requires a code review. [helmet usually]

xdisplay - Copy the X session authentication data from the client user
	to another's (the new effective user's) ~/.Xauthority file, then
	wait for the session to exit and maybe delete the creds (we don't at
	present delete the creds, since they could have copied them and
	might have X clients still open).  Lets you start a GUI as another
	login w/o opening X to the whole machine (or using ssh X
	forwarding).

--
ksb, Sep 2010