
Treeps is a powerful program, it opens up much system related information
for viewing and at the same time provides a mechanism for users to
perform actions on processes. While this is highly beneficial it also
raises some security and administration issues. What information should
end users be able to view? What actions should a user be able to perform
on their own process? On others users processes? e.g. Should a user be able
to renice their own processes to increase priority?

Initially, the unreleased version of the program was written with the
single user workstation/system in mind, as such any information could be
viewed and any action was permitted. Since the program is run setuid,
this provided access to information and operations that a normal user
would not have. As the program has matured I have been gradually changing
this security model to one which takes into account other configurations.

My first step, before releasing it publicly, was basically to make any
questionable security feature a compile time option. Then by default,
erring on the side of caution, turn such features off.  For example
the signaling of any process was only permitted when the program was
compiled with the TRUSTED_USER symbol defined to 1(by default it's
set to 0). Thus users can only signal their own processes, unless you 
specifically modify the right include file.

In the last release(1.1.0) I added the ability to renice processes and to
trace them. When I added these new features I initially let the setuid
control whether or not the feature worked. In otherwords if the program
was setuid-to-root and a user tried to renice their own processes,
then it would let them both decrease and increase the nice value. I
added code to not allow them to renice other users processes. Then I
added a compile time flag to enable/disable this feature. This was good,
but since these features were bound at compile time it meant that binary
distributions could not tune these as desired. In otherwords a binary
distribution was stuck with the security model I though was best(
generally it probably was, but I'm sure it's not always what's wanted).


On GNU/Linux and the latest releases of UnixWare and Solaris, you can run 
the program non-setuid to root. This adds another level of security
as the end user can only do non-setuid root activities. However, this
limits the program in the following ways:

	Can't renice own processes with negative values

	Can't trace any process

	Can't signal processes not owned by user, even if compiled TRUSTED

	Can't gather some fields for processes owned by other users

but the program is still quite usable.  On older releases of
Solaris/Unixware the program has to be setuid-to-root to even function
at minimal levels. On these systems I wouldn't even recommend trying to
run treeps without it.


Future releases of treeps will continue to improve the security model. In
particular the next major release will "objectify" the processes and
provide per process actions. Each action will have some form of global,
group and per user security permissions.  Also certain data fields
will also get permission attributes to protect them from prying eyes(if
desired).


