Bug#488821: apache2-suexec: suexec configuration change demands extensive system changes
Hi, Stefan,
First, I would like to apologize for my rather terse initial
message---it took me a while to figure out that I needed to install a
new package (perhaps it warrants a recommends or at least suggests, so
it shows up somewhere?), and then once it was installed, a while longer
to figure out why that didn't help.
Second, I would like to thank you for your effort in maintaining
apache---it's an important piece of software that I suspect only earns
you annoying messages like this when it breaks, and precious little
thanks when it "just works".
So, even though we disagree on this particular issue, I do appreciate
the time and energy you put forth to maintaining it. Thank you.
That said, well, I hope this message will persuade you to undo this
change. :)
On Tue, 1 Jul 2008 21:58:57 +0200
Stefan Fritsch <sf@debian.org> wrote:
> Nearly every configuration change in apache will break some system
> somewhere. That does not make this a critical bug.
It is certainly true that arbitrary configuration changes in
apache run the risk of breaking some system somewhere. There's an
argument to be made that that's a reason not to make arbitrary
configuration changes. :)
Regardless, "breaks existing installations of unrelated software" is
part of the definition of a critical bug in the guidelines, and that's
precisely what I experienced so I stand by my classification.
Go ahead and downgrade it if you truly believe critical is
inappropriate---I think you'd be wrong, but I haven't indulged in
"retaliatory reclassification games" in many years.
> Allowing suexec to change to random system users is bad from a
> security point of view. Therefore the minimum uid of 100 should be
> changed to some higher value. Now the question is if it is possible
> to make that change in a less disrupting way. A compromise would be
> to raise it to 200 and not 1000. This would exclude automatically
> created system accounts on most systems and mean a significant gain
> in security. Would this be helpful? Is the user you want to switch to
> created by some Debian package or have you created it manually?
That the bound is arbitrary seems to me a pretty clear indicator that
it's value for security is limited.
While I could definitely understand disallowing root, and even userids
that are guaranteed to be on the system, and thus represent known
quantities---which is what the old limit did---you can have no
knowledge of exactly how many or to what use userids are assigned and
how they are used.
I would also be surprised if there were no one else out there who had
used a system user for an installed system on one of their machines.
If you consider the documentation for adduser:
A home directory is created by the same rules as for normal users.
The new system user will have the shell /bin/false (unless overridden
with the --shell option), and have logins disabled. Skeletal configu-
ration files are not copied.
That sounds like just what I want as a user to own a bunch of processes
and their associated files---which is why I created a system user.
There is nothing in the documentation that suggests that it is
inappropriate for a system administrator to use this facility for him
or herself.
Debian is used for a lot of non-end-user machines; a serious system
administrator is going to know about things like this. To penalize
them for taking advantage of it would be unfortunate.
Or even consider this from the Debian Policy manual:
9.2 Users and groups
9.2.1 Introduction
The Debian system can be configured to use either plain or shadow
passwords.
Some user ids (UIDs) and group ids (GIDs) are reserved globally for
use by certain packages. Because some packages need to include files
which are owned by these users or groups, or need the ids compiled
into binaries, these ids must be used on any Debian system only for
the purpose for which they are allocated. This is a serious
restriction, and we should avoid getting in the way of local
administration policies. In particular, many sites allocate users
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and/or local system groups starting at 100.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So the policy manual even seems, if not to endorse this, at least to
recognize that it happens, and that software for Debian systems should
be as respectful of it as possible.
Parenthetically, if we're really talking security, we're virtually
guaranteed to have a user with a uid of 1000, and it's likely to be the
person who installed the system and does a lot of sudo and so
forth---sounds like a better vector for attack than uid 106, which is
the rbldns user on my machine. That doesn't own _anything_.
Finally, when one considers the *many other* constraints on suexec---the
executable must in in a particular location, it must be owned by the
user in question, etc---I think your assertion that there are gains in
security as a result this change in an arbitrary lower bound is
questionable.
But if you truly feel that this arbitrary change is necessary for
creating secure systems, I don't know what else to say to convince
you. At least be kind enough to your users to announce in NEWS.Debian
that you might be about to break their system. :)
Mike.
Reply to: