Re: Does Debian need to enforce a better Security policy for packages?
On Mon, Oct 22, 2001 at 09:31:38PM +0200, Christian Kurz wrote:
> What does security policies for building a debian package exactly have
> to do with securing a debian box? System administrator reading this
> document will be interested in tips and howtos on improving the security
> on the boxes, that he administrates. He's certainly not interested in
> knowing how to securely build a debian package.
The point is. I'm starting to think on changing the document title
to something on the lines of "Debian Security Manual" and go a little
deeper into Debian security stuff (advisories, the security team, etc..)
> That will soon be discovered and I would say those maintainer is facing
> definetely problems.
Migh I remember you that we are not (IIRC) doing a source code
audit of packages. That "soon" is supposing that his package is widely
used and the mischief promptly discovered.
> > lintian does check many issues regarding policy, but it does not test
> > potential security problems.
> Which is correct, since lintian is only written for checking policy
> compliance. If you want a tool checking for security problems, you
> should write another new tool for this purpose.
Not exactly right, policy does talk about security related issues,
and lintian should check them. For example:
11.9. Permissions and owners
The rules in this section are guidelines for general use. If
necessary you may deviate from the details below. However, if you do
so you must make sure that what is done is *secure* and you should try
to be as consistent as possible with the rest of the system.
(emphasis is mine)
> > So. Since we do not source code audits of incoming packages and
> > this kind of issues are not detected automatically... does this leave
> > the Debian distribution open to attack if a developer box gets hacked
> > into?
> No, new packages are not automatically becoming available for everyone
> and will be reviewed before. So this doesn't leave the distribution open
> for that kind of attacks you imagine.
So, then, for the record (i.e. the manual) what kind of reviews
are made for incoming/new packages (besides lintian checks). I do know
that the archive maintainers do this stuff, could someone introduce me to
what reviews (security-wise) are made?
> No, because that's not the purpose of lintian. Write either a new tool
> for that purpose or leave it. But be aware that it's very difficult to
> detect all kinds of possible attacks or trojans that one could create.
I agree. However, with the Debian package format becoming
increasingly popular, it does have some flaws (IMHO, I might get smacked
for saying this :) which might be used to introduce simple troyans.
Regardless of the package contents (which might
be a troyan by itself) having the post-pre-install-remove script as a root
user with an unrestricted shell (or perl, or whatever) could turn into
potential problems on the long term.
*If* the contents are troyaned, the user still has to run them
(unless the package installs daemons or cron items, or simply calls them
himself) in order to be affected. However, installation scripts are run
regardless of the package contents.
So, is it possible to limit those scripts or am I just thinking on
trying to put a fence around the desert? (not really sure if that's the
appropiate expression BTW :P