Re: openpkg user (cw, cw-r, cw-n)
On Fri, Jan 24, 2003, Ralf S. Engelschall wrote: On Fri, Jan 24, 2003, [EMAIL PROTECTED] wrote: while beeing a nice idea I am not 100% convinced that introducing the three openpkg users gains much more than it costs. [...] Fellows, i just want you to know that i tried to work off this thread and improve the Handbook and the FAQ. New content http://www.openpkg.org/doc/handbook/openpkg.html#security-usergroup http://www.openpkg.org/faq.html#uid-security http://www.openpkg.org/faq.html#uid-query Changes http://cvs.openpkg.org/chngview?cn=8521 [Handbook] http://cvs.openpkg.org/chngview?cn=8523 [FAQ] -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: openpkg user (cw, cw-r, cw-n)
On Sat, Jan 25, 2003, Bill Campbell wrote:
while beeing a nice idea I am not 100% convinced that introducing the
three openpkg users gains much more than it costs.
...
Especially when using openpkg to employ deamons (like apache, postfix,...)
it starts to become an annoyance to have the special openpkg users.
(Without root permissions it is difficult to give the directories correct
ownership when installing an openpkg rpm)
That's the reason why the _general_ rule in OpenPKG is: build as the
management user (%{l_musr}, in your case cw) and install as the super
user (%{l_susr}, in usually all cases root). But this has nothing
to do with the extra restricted and nobody user/group ids. This is
just inherently necessary because daemons have setuid and other stuff
which just require super user priviledges. So, sure, for things like
Postfix it is _always_ necessary to install as root to result in correct
ownerships, etc.
Wouldn't it then make sense with these general rules to have the
%{l_prefix}/RPM/{SRC,TMP,PKG} directories owned by %{l_musr},%{l_mgrp} and
everything else by %{l_susr},%{l_sgrp}? As it is now with the default
ownership of the openpkg hierarchy the management user, developers can
write into the installation areas, accidentally nuking things just as in
the traditional RPM environment when everybody builds a root.
I've found some interesting bugs in my old RPM spec files while converting
to openpkg where I've changed things in the underlying system accidentally.
On the other hand, I've missed a few where I was able to write into the
openpkg working (install destination) directories while building as the
management user.
For OpenPKG there are two scenarios:
1. system-level deployment (i.e. --prefix=/usr/opkg --user=opkg --group=opkg):
l_susr/l_sgrp root/wheel
l_musr/l_mgrp opkg/opkg
l_rusr/l_rgrp opkg-r/opkg-r
l_nusr/l_ngrp opkg-n/opkg-n
2. user-level deployment (i.e. --prefix=/u/rse/opkg --user=rse --group=rse):
l_susr/l_sgrp root/wheel
l_musr/l_mgrp rse/rse
l_rusr/l_rgrp rse/rse
l_nusr/l_ngrp rse/rse
The first is the classical admin system purpose way of installation,
the second is the alternative single-user private purpose way of
installation. It is clear that not all packges work for (2) because
some (e.g. Postfix) require distinct user/group ids or want to bind to
priviledged ports, etc. But 95% of all packages also can be used in
situation (2). And (2) prevents you from installing any files owned by
root/wheel, of course.
Additionally, the management user is really intended to both build and
install the packages, so it is correct that they are owned by him. It is
just because of the 5% of packages from above and the confusion people
would have (for which package I've to run rpm -Uvh as root and for
which I do not?) that we declared the general goal in OpenPKG that rpm
--rebuild is performed as the management user and that rpm -Uvh is
performed by the super user (although we know that in 95% of the cases
this would be not really necessary, of course).
So, owning the files by the super user would both break situation (2)
and really _technically require_ super user priviledges for rpm -Uvh
all the time. And although certainly nasty, the nuking of files during
built-time should be a developer only issue (so does not count that
much) while the other issues are end-user issues (which have to count
more). The OpenPKG project developers build packages actually under
their personal user/group to avoid this nuking easily during package
development. But end-users get tested packages where no such nuking
should exist, so they are usually not affected by the nuking problem --
at least in theory ;-)
But you're right: perhaps we should not even recommend to use the
management user for building, but the nobody user. Hmmm... your points
are worth considering more, because here we have a subtle issue on
which we should investigate more and discuss it in depth. What are the
opinions of others?
This ties back to my question last week about the security implications of
running package rc.%{name} files which are writeable by users other than
root. If the working directories are owned by %{l_susr} (defaulting to
root), this goes a long way towards securing these scripts. A further step
would be for the etc/rc script to check the ownership of any files, and
their directory components running with root priviledges to insure that
they're only writeable by %{l_susr}.
Perhaps you've missed by reply, but from a security point of view IMHO
we do not gain very much by doing it just this way. Because the problem
is that all rc scripts theirself call other programs, etc. And this way
all the super user ownerships and tests are useless as long as just a
single program of this is not owned by the super user, aren't they?
Ralf S. Engelschall
[EMAIL PROTECTED]
Re: openpkg user (cw, cw-r, cw-n)
On Sun, Jan 26, 2003 at 10:24:58AM +0100, Ralf S. Engelschall wrote:
On Sat, Jan 25, 2003, Bill Campbell wrote:
...snip
But you're right: perhaps we should not even recommend to use the
management user for building, but the nobody user. Hmmm... your points
are worth considering more, because here we have a subtle issue on
which we should investigate more and discuss it in depth. What are the
opinions of others?
This ties back to my question last week about the security implications of
running package rc.%{name} files which are writeable by users other than
root. If the working directories are owned by %{l_susr} (defaulting to
root), this goes a long way towards securing these scripts. A further step
would be for the etc/rc script to check the ownership of any files, and
their directory components running with root priviledges to insure that
they're only writeable by %{l_susr}.
Perhaps you've missed by reply, but from a security point of view IMHO
we do not gain very much by doing it just this way. Because the problem
is that all rc scripts theirself call other programs, etc. And this way
all the super user ownerships and tests are useless as long as just a
single program of this is not owned by the super user, aren't they?
It's been a long time since I looked closely at the code for COPS, but if I
remember correctly, this what the the kuang tests do, check down through
the chains of execution for files with suspicious ownership. Looking at
the code I have here which hasn't been updated since 2000 or so, it doesn't
look like it deals with the current Linux crontab model so doesn't parse
the /etc/crontab file (I'll have to do a bit of hacking tonight :-).
I've found COPS to be very useful, particularly in evaluating a vendor's
default installation. In one case, SCO released a version of OpenServer
with 777 permissions on ``/'' and throughout their symlink hell,
/opt/SCO This happened between the final beta cut and FCS (First
Customer Ship). I found it with COPS, immediately notified some friends at
SCO, and to their credit SCO stopped shipping that version until they recut
it with the holes closed.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``Freedom from prices is freedom from responsibility. You can simply pass
laws, using the magic wand of government to satisfy your own desires at
unspecified costs to be paid by others.'' -- Thomas Sowell Aug 2000
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
Re: openpkg user (cw, cw-r, cw-n)
On Fri, Jan 24, 2003 at 10:11:52AM +0100, Ralf S. Engelschall wrote:
On Fri, Jan 24, 2003, [EMAIL PROTECTED] wrote:
while beeing a nice idea I am not 100% convinced that introducing the
three openpkg users gains much more than it costs.
...
Especially when using openpkg to employ deamons (like apache, postfix,...)
it starts to become an annoyance to have the special openpkg users.
(Without root permissions it is difficult to give the directories correct
ownership when installing an openpkg rpm)
That's the reason why the _general_ rule in OpenPKG is: build as the
management user (%{l_musr}, in your case cw) and install as the super
user (%{l_susr}, in usually all cases root). But this has nothing
to do with the extra restricted and nobody user/group ids. This is
just inherently necessary because daemons have setuid and other stuff
which just require super user priviledges. So, sure, for things like
Postfix it is _always_ necessary to install as root to result in correct
ownerships, etc.
Wouldn't it then make sense with these general rules to have the
%{l_prefix}/RPM/{SRC,TMP,PKG} directories owned by %{l_musr},%{l_mgrp} and
everything else by %{l_susr},%{l_sgrp}? As it is now with the default
ownership of the openpkg hierarchy the management user, developers can
write into the installation areas, accidentally nuking things just as in
the traditional RPM environment when everybody builds a root.
I've found some interesting bugs in my old RPM spec files while converting
to openpkg where I've changed things in the underlying system accidentally.
On the other hand, I've missed a few where I was able to write into the
openpkg working (install destination) directories while building as the
management user.
This ties back to my question last week about the security implications of
running package rc.%{name} files which are writeable by users other than
root. If the working directories are owned by %{l_susr} (defaulting to
root), this goes a long way towards securing these scripts. A further step
would be for the etc/rc script to check the ownership of any files, and
their directory components running with root priviledges to insure that
they're only writeable by %{l_susr}.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``We believe...that a mugger will kill you in the half-second it takes to
draw from the holster, but won't harm you while you dial the police on your
cell phone, talk to the dispatcher and wait half an hour for officers to
arrive.'' -- Gun-Control Net-work Credo
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
