# $Id: TODO,v 2.78 2012/09/25 18:48:27 ksb Exp $

Sanity:
-------

Check all jacket paths and executable files for unsafe modes all the
way up to slash, but only complain once for each unsafe directory.
Group write for a group is usually bad, owner write that is not root
or the real or effective uid is bad as well.

Also if the program you are running is setuid (setgid) and you have specified
euid!=uid (egid!=gid) then we might need to talk.

Future:
-------

But maybe write a conversion script for Alec Thomas's version of op?

Maybe (I don't like this) allow op to read the configuration from LDAP.
Each entry in the directory would be part of the configration of a rule.
This would allow a network service to provide the configuration to a whole
cluster in real-time.  Sudo supports something like this I think it is a
Bad Idea for a lot of reasons -- I'd rather see a program that pulled the
LDAP when asked, then built the configuration files.  Better yet, just use
msrc or msrcmux to build them.

Note CheckPath could check more, we could vetch if you include the client's
${PATH} in there AND are actually escalated.  We could complain if you set
$PATH and ran internal echo (the doesn't search $PATH).  We could basically
call FinishExec to expand markup where possible, but I think that's going a
bit beyond.  Not that I didn't figure out how to do it, you see.


Tiny nits:
----------
The %f.login@g (group) implies (mildly) that we need %f.group@u (user or
login) to allow any group with login as an explicitly listed member.
I didn't implement it as I'd have to duplicate most of MapGid.  I'm sure
I'll put it in the major point next release (3.1).

The rtprio(2) {aka idprio} calls in FreeBSD would be nifty.
	nice=rt{0..31} | id{0..31} | [t]-20..20
(t for traditional).  I believe this would be useful, in spite of the
fact that rtprio and idprio exist.

%g@u=REs and !g@u=REs should (maybe) look at primary login group, or there
should be %g@l (or %g@p) to turn the password file into a membership list
to search like %g@u searches the group file's membership.  Humm, that path
of reasoning leads to more cases than I'd like (but it is not hard code
as a helmet).


Not missing, but you might think so:
------------------------------------
Building a symbolic link to op from the name "sudo" is just plain funny
(and I have a script "sudop" that is most people can't tell from sudo).
But if you name a group "sudo" you can even make it more useful, see
SENTINEL in the manual page.

The daemon option doesn't set a session id (via setsid) because we want it
in the same process group as any jacket above it.  See daemon(8), or my
version of same.

I'd like %g to expand in password context to the password on the group.
Sadly most "shadow password" systems don't shadow the group file, so most
systems discouraged them (and "newgrp" which is sad).  We don't want to open
ourselves to a possibly compromised password.  AFAICT only some versions of
Linux do shadow group files correctly.  If you want group passwords use
(or write) a pam module that checks them.


Ideas to continue op's evolution:
---------------------------------

We could allow a jail (FreeBSD) parameter, or command-line option.
This is really not much better than running jexec(8) from an
in-line script, so I didn't add it.  And jail support is limited
to only FreeBSD mostly.  (I do love them as light-weight VMs!)

A parameter "cwd=RE" would be nice, because that would let us check
references to "." in a command against a (possibly know) set of dirs.
But it goes against the general flow, and the helmet to check is
trivial, but the check code can't see helmet invariants.  Humm, looks
like we may have to do that in version 3 (or not at all).  I'm not
going to fork helmets under -S and have them check context.

Maybe allow rule options to match (not match) via %u (!u) or %g (!g)
attributes:
	%u.name %u.passwd %u.uid %u.gid %u.group %u.class %u.change,
	%u.expire, %u.gecos %u.dir (aka %u.home_dir) %u.shell
and
	%g.name %g.passwd %g.gid %g.members %g.count (total members)
this would make it more like %f, but I've never needed dir|gecos|shell
matches.  And you can do it in the rare case with a helmet and $g + $u.

Helmets _could_ be empowered to send access rights back to op for the
escalated process, if you wanted to be really cool.  For example open a
privileged TCP/IP port for Apache then send it as fd#0.  This would be easy
to implement with my div_select code.  Comment in ExtFile.

Maybe -j pid?  I think this is a bit much, and a jacket could some of it.
If we allow a -j pid and and a $j for that process-id (`job' since $p is
taken by PAM) and %J for the op process-id.  Then we could limit:
	%j.pid=RE
	%j.uid=RE
	%j.file=RE
	%j.command=RE
	%j.ppid=RE
	%j.tty=RE	# "-" for no /path for yes
	%j.flags=RE	# (c|-)(s|-) for ctty, session leader
	%j.uid=%u|%f|%J.x|RE
	%j.euid=%u|%f|%j.x|RE
	%j.user=<same>	# for login name, not just numeric
	%j.euser=<same>
	%j.gid=
	%j.egid
	%j.group=
	%j.egroup=
	%j.jail=RE.
	%j=		# would be shorthand for %j.pid

The we could write rules to allow someone to truss 2 application logins
and test on their own pids:
	truss	/usr/sbin/truss -D -p $j ;
		%j.login=^app1$,^app5$ ...
In the context of %j.<any> the %J markup matches the parallel <any> value.
So "%j.gid=%J" means "%j's gid is the same as the Customer's real group".

This would add about ~655 lines to op.m, I think.  It would parallel %f
very closely. We'd fill in (in Craving?) two structs (for %j and %J) and
have a function to expand a %j.x into a buffer, then a match (not-match)
loop like %f has.  Easy if we have /proc mounted, impossible if we don't.
But is it really useful enough to add to the core program?  Not today.

--
Kevin S Braunsdorf (ksb), Jul 2012, install at ksb dot NPC Guild.org