Packaging questions regarding plan
I have run into a few situations regarding packaging plan that I would
appreciate some comments on. I will begin by picking up where I left off
in a conversion before I left town for a couple of weeks.
On Fri, 6 Jun 1997, David Frey wrote:
> Hi Colin,
>
> On Thu, Jun 5 1997 14:59 EDT "Colin R. Telmer" writes:
> > if run by root or setuid root, netplan switches to "nobody". The UID
> > and GID of <nobody> are compiled in, not determined at runtime. netplan
> Bad.
> > will refuse to run setgid-but-not-setuid root.
> Huh? Setgid root is useless, isn't it?
Thanks for the reply. I am somewhat confused by this whole thing so I will
try to clarify the problem. First of all, netplan, the program that allows
a group of users to access a common plan database, is designed to be
hardwired with uid and gid of nobody: (from the README)
- change NOB_UID and NOB_GID to the user and group ID of user <nobody>.
On SVID machines both are 60001. You may find a line that begins with
something like "nobody:*:60001:60001:" (uid:gid) in /etc/passwd.HP/UX9
uses 30001, IBM 4294967295, SunOS4 65534, and Convex -2:60001. Always
choose an account with minimal access privileges! 0:0 will be rejected.
Given this, using chmod to set user or group ID on execution(s) is
useless. It will always run as the uid hardwired in. In the same note,
David Frey (listed below as footnote [1]) advised me that netplan should
not run as nobody given it accesses files (it reads users public
~/.dayplan files and it also reads non-user appointment files such as
vacation lists from /var/lib/plan/netplan/). Also, in a second footnote I
have copied the security information included within the README for
reference. The previous maintainer of plan (Christoph Lameter) had a
postinst that created a system user called netplan and then installed the
netplan executable with userid netplan so that when netplan was started at
boot, it ran as user netplan. This version of plan will not allow that do
to the hardwiring above. To my knowledge, there are two ways to get around
this:
1) Use an existing uid and gid from the already defined ones in the base
system.
2) Create a new system user called netplan using specified uid and gid and
then also use this uid and gid to hardwire in during compilation. Here
I would assume that I need to contact the base-system maintainer and
ask for a new uid/gid combination as in the policy manual.
What should I do?
Finally, a question that I probably should have asked initially - plan
works quite well with lesstif but not perfectly. ALT-f does not bring up
the file menu and some help windows aren't optimally sized. However, I
have been using it like this for some time and find these problems are
minimal and that I am quite happy with lesstif overall. Is distributing a
package dynamically linked to lesstif ok or will this add to frustration
improperly aimed at debian if the user does not know that the small flaws
are due to lesstif?
Footnote [1]
> > 2) Do I really need to change the suid of netplan from nobody to netplan?
> Yes, it is better if nobody doesn't have any files belonging to himself,
> since other processes might be running as nobody too.
Footnote [2]
Network Security
----------------
Here is information that your system administrator will want to know. IP
services are potential security risks if written improperly. I make no
promises that netplan is completely secure but I made every effort to
avoid the usual pitfalls. netplan is small enough so you can check for
yourself. If you have stringent security policies, do not trust netplan.
Apart from the ability for everybody to access everybody else's
non-private appointments, netplan must satisfy general security concerns.
In particular, it must not be usable to open network security holes that
allow access to files that have nothing to do with plan. The security
features are:
* if run by root or setuid root, netplan switches to "nobody". The UID
and GID of <nobody> are compiled in, not determined at runtime. netplan
will refuse to run setgid-but-not-setuid root.
* netplan does not execute other programs (this is one of the reasons why
there are still pland daemons).
* netplan cannot be used to access files that are not in its home
directory, /usr/local/lib/netplan by default. Absolute paths are
converted to paths relative to the home directory.
* netplan refuses to access softlinks and files that have more than one
hardlink. This may be inconvenient at times, but without this the user
who started netplan would be wide open for the entire net.
* netplan is not sendmail. All buffers are checked for overflows.
* netplan is Purify'd.
--
Colin R. Telmer, Institute of Intergovernmental Relations
School of Policy Studies, Queen's University
Kingston, Ontario, Canada, K7L-3N6
(613)545-6000x4219 telmerco@qed.econ.queensu.ca
PGP Fingerprint = 09 E9 DA 66 9C EE 33 DC B8 3B 97 0E 01 BC EC 0B
PGP Public Key at <URL:http://terrapin.econ.queensu.ca>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: