On 23/10/01, Javier Fernández-Sanguino Peña wrote:
> 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..)
Well, advisories still would fit into a "Securing Debian Manual" because
they are an important part of increase the security of the system
someone is responsible for. I don't know what exactly you want to write
about the security team, but maybe it would also fit. Information about
securing the build system and how to securely build Debian packages
should be an extra document for interested developers in my humble opinion.
> > 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
Do you know how difficult and time-consuming it really is to do a manual
source code audit? Also the available programs for source code audits
can only give you hints which parts of a program might be suspicious, but
you still would have to verify everything by hand to be really sure.
> audit of packages. That "soon" is supposing that his package is widely
> used and the mischief promptly discovered.
I don't think so, because any mischief that isn't triggered by some
obscure situation or configuration, will be very fast discovered. And
also the package doesn't need to be widely used, since we have quite
some people following unstable and new packages closely, which would
then report bugs.
> > > 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)
Did you read just this small paragraph or the whole section 11.9 from
the policy? If you have read it, then you should have noticed that it
clearly talks about useful permission for certain cases, which don't
open security holes. It absolutely is not talking about how to change
permissions and owners to have a really secure system. That would
involve for example also checking for setuid,setgid files or
world-writable directories for example.
> > > 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?
Please ask the ftp-masters about this issue, since they are the best
authority you can ask for getting the necessary information about this.
> > 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.
I would say, that not only the Debian package format has it's
shortcomings, but that the same applies for the rpm format also. There's
no format available which doesn't have any short-coming. [0]
> 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.
You know that a restricted shell, for example rbash, is not going to
stop someone from breaking out of it, getting a root shell and still
running his malicious code? And perl shouldn't be involved in any script
that is run prior or after installation of a package. After looking a at
rpm spec file, it seems like you can achieve the same with an rpm
package.[1]
> 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
You keep talking about limiting those scripts, but I'm seeing no useful
or working solution from you about this problem. May I suggest that you
first try to think about a limitation for those scripts, that is still
useful, that works fine and which isn't easy to circumvent like a
restricted shell?
Christian
[0] Well, if there's really some format overcoming those short-comings,
then please tell me about it.
[1] If anyone has more insight into rpm packages, the building process
and scripts run prior or after installation, then please correct me if
I'm wrong.
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Attachment:
pgpYY4JxGiSXV.pgp
Description: PGP signature