Re: Mozilla/Firefox PostScript/default security problems
On Fri, Jul 09, 2004 at 06:38:49PM -0500, Brad Sims wrote: If you want postscript back; simply grab the source deb and roll your own; just edit rules under the debian folder. Delete the '--with-xprint' and '--disable-postscript' lines and do 'dpkg-buildpackage -rfakeroot'. However I did give the debs a version number of 99 to keep apt from updating them until there is a new mozilla version from upstream. I'd like a black and white clarification of the impact of the change so I know for certain whether to be incredibly pissed off at the packager or not: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] I do this as a matter of course, every single day to archive data important to projects I work on. I don't have time to rebuild mozilla myself all the time, so if the answer to this is that I cannot... I have four choices in descending order of desirability: * find someone else with a repository that overrides it. * freeze forever / manually update selected packages. * abandon Debian mozilla * abandon Debian If it is true that someone out there is playing with things important to my means of making a living, I do not appreciate it in the least. -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
On Sat, Jul 10, 2004 at 10:47:08AM +0100, Dale Amon wrote: On Fri, Jul 09, 2004 at 06:38:49PM -0500, Brad Sims wrote: If you want postscript back; simply grab the source deb and roll your own; just edit rules under the debian folder. Delete the '--with-xprint' and '--disable-postscript' lines and do 'dpkg-buildpackage -rfakeroot'. However I did give the debs a version number of 99 to keep apt from updating them until there is a new mozilla version from upstream. I'd like a black and white clarification of the impact of the change so I know for certain whether to be incredibly pissed off at the packager or not: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] Yes. Printing PS to a file is still possible. What is removed is the ability to have Mozilla/Firefox execute an external command (e.g. lpr) in order to print. I do this as a matter of course, every single day to archive data important to projects I work on. I don't have time to rebuild mozilla myself all the time, so if the answer to this is that I cannot... I have four choices in descending order of desirability: * find someone else with a repository that overrides it. * freeze forever / manually update selected packages. * abandon Debian mozilla * abandon Debian If it is true that someone out there is playing with things important to my means of making a living, I do not appreciate it in the least. -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Magnus Therning(OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] http://magnus.therning.org/ The real problem we face with the web is not understanding the anomalies, it's facing how deeply weird the ordinary is. -- David Weinberger signature.asc Description: Digital signature
Re: Mozilla/Firefox PostScript/default security problems
On Sat, Jul 10, 2004 at 12:47:18PM +0200, Magnus Therning wrote: Yes. Printing PS to a file is still possible. Thanks. I had visions of all sorts of extra work in order to just stand still. Now I can forget about this and go back to writing my mail address verify daemon... -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
Excuse the cross posting, but many are discussing on all of these lists. On Sat, 2004-07-10 at 06:47, Magnus Therning wrote: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] Yes. Printing PS to a file is still possible. What is removed is the ability to have Mozilla/Firefox execute an external command (e.g. lpr) in order to print. H. Now since printing to a file is fine. (DING, light goes on.) What say we make a PIPE and attach it to something. Oh like say a print queue process, a redirect or something similar. That would allow us to use nearly anything we wanted to. Seems possible it'd be a simple process, given you could know what you are doing. Even for Epiphany or Galeon. Heck, we could even have insert favorite desktop environ here do the work. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Mozilla/Firefox PostScript/default security problems
On Saturday 10 July 2004 5:47 am, Magnus Therning wrote: I'd like a black and white clarification of the impact of the change so I know for certain whether to be incredibly pissed off at the packager or not: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] Yes. Printing PS to a file is still possible. What is removed is the ability to have Mozilla/Firefox execute an external command (e.g. lpr) in order to print. However, if you are one of the many people for whom xprint either won't start or function properly you will be unable to print at all. Read this bugreport and see if Xprint is still such a great idea... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257731 If xprint won't start, mozilla will not even open the print dialog to even /try/ piping it to lpr. That is absolute fact, I tried it myself. No go. See the other buglistings: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xprt-common Now correct me if this is wrong, mozilla is Free Software; however due to the fact that it now actually requires xprint, which appears to be Non-Free software misfiled as Free Software (see #250887). Isn't that a pretty major violation of Debian Policy? Now I realize that Mozilla merely suggests xprint; however it now won't print without it. I dunno about you; but I get a bad taste in my mouth about such legalistic reindeer games to avoid conflicting with Deb-Policy. -- It's politically correct to hate guns; it's not politically correct to hate free speech. The results speak for themselves. -- Jay Maynard in the SDM
Re: Mozilla/Firefox PostScript/default security problems
On Sat, 10 Jul 2004 11:19:03 -0400 Greg Folkert [EMAIL PROTECTED] wrote: Excuse the cross posting, but many are discussing on all of these lists. On Sat, 2004-07-10 at 06:47, Magnus Therning wrote: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] Yes. Printing PS to a file is still possible. What is removed is the ability to have Mozilla/Firefox execute an external command (e.g. lpr) in order to print. H. Now since printing to a file is fine. (DING, light goes on.) I'd double check that. My impression was that the PostScript generator had the security issue in which case removing the ability to execute an external command would be pointless. The previous poster may have been using Xprint which would allow the user to print to file but not using the PostScript generator. I don't know for certain but you might want to check. Mike -- Greedo shoots first? Not in my Star Wars. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
On Sat, 10 Jul 2004, Michael B Allen wrote: My impression was that the PostScript generator had the security issue Can someone please state, for the record, definitively and precisely what this security issue is? The fact that PS is a turing complete language isn't a security issue, beyond the fact that you shouldn't blindly execute untrusted PS. (Just like you shouldn't blindly execute make files, or C code, or perl scripts...) Perhaps I've missed something, but everything that I've read in the threads so far amounts to people either assuming that there's an issue and not defining it, or attempting to figure out where the issue is. Don Armstrong -- Personally, I think my choice in the mostest-superlative-computer wars has to be the HP-48 series of calculators. They'll run almost anything. And if they can't, while I'll just plug a Linux box into the serial port and load up the HP-48 VT-100 emulator. -- Jeff Dege, [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
* Don Armstrong: Perhaps I've missed something, but everything that I've read in the threads so far amounts to people either assuming that there's an issue and not defining it, or attempting to figure out where the issue is. This summary is correct as far as I can see. No real security issue has been disclosed so far. Two things could lead to vulnerabilities: * It's possible to use scripting to set another print command. * Untrusted content might be put verbatim into the Postscript file. The latter case shouldn't be a problem because viewers and print spoolers should not assume benign Postscript files (if they do, it's their fault, not Mozilla's). If the first issue is a problem, printing to a pipe should be disabled, but not printing to a file (or printing should be made unscriptable). I find these rumors quite disturbing. Some people are trying very hard to put Mozilla's security efforts in a very bad shape. First the shell: protocol handler issue (on Windows) that has been known (in principle) since 2002, and now this mess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
Has anyone invited our Mozilla packager to participate in this discussion? -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
On Sat, 10 Jul 2004 12:00:07 +0200, Dale Amon wrote: I'd like a black and white clarification of the impact of the change so I know for certain whether to be incredibly pissed off at the packager or not: If I were to dselect today, would I still be able to print to file a website page as ps? [Y/N] As far as I can tell, the answer to this is a big fat maybe. It depends on whether Xprint works for you -- Xprint generates the same postscript whether you print to a file or to a printer, so whether you can get this far (and whether the postscript is okay) depends on whether you have the magic touch on Xprint. You have to try Xprint to see if it works for you. IMO, you should be pissed at the package manager, for removing a print path that works for many, whose replacement does not work for some, with claimed reasons being that the old way doesn't work for everyone (neither does the new one) and that it is insecure (which so far, no one has shown any real evidence of). Sure, I can roll my own package or grab the upstream, but I use Debian for its fabulous package management. I don't want to mess with tracking versions or rebuilding the deb regularly. Reid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla/Firefox PostScript/default security problems
On Thursday 08 July 2004 7:18 pm, Reid Priedhorsky wrote: Googling and searching the bug database only yielded a vague claim about a remote exploit (bug #247585). I also asked over on debian-user and while the flurry of replies showed that the removal decision was controversial if not unpopular, no one gave any information on the security problems. debian-devel has not turned up anything so far either. Best anyone on debian-user or in #debian up on freenode can tell me the only one to notice the potential exploit (frankly I worry more about a meteor hitting the pc) is the one who removed postscript and who closes wishlists asking it back with wont-fix. Upstream still prints via postscript/default; for what it's worth. As I understand it the potential is that postscript as nearly turing-complete it can potentially run commands on your machine while printing L337 |-|40r Du|)3's web page. Like I said, not all that likely to actually happen in real life. But if anyone has more info I too would like to hear it. If you want postscript back; simply grab the source deb and roll your own; just edit rules under the debian folder. Delete the '--with-xprint' and '--disable-postscript' lines and do 'dpkg-buildpackage -rfakeroot'. However I did give the debs a version number of 99 to keep apt from updating them until there is a new mozilla version from upstream. -- How dare the government intervene to stifle innovation in the computer industry! That's Microsoft's job, dammit! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mozilla/Firefox PostScript/default security problems
Hello all, I have just discovered that the old-style printing option PostScript/default is gone from Firefox and probably Mozilla (I don't use Mozilla). Apparently a major reason for this is that the PostScript printing engine that was removed has security problems. Does anyone have any solid references on these security problems? Googling and searching the bug database only yielded a vague claim about a remote exploit (bug #247585). I also asked over on debian-user and while the flurry of replies showed that the removal decision was controversial if not unpopular, no one gave any information on the security problems. debian-devel has not turned up anything so far either. Sorry for cross-posting so much. I did post on debian-devel before I knew debian-security existed. I figured the audience here might follow security things in more detail. Thank you for your time, Reid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.03.07.1054 +0100]:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
me too...
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
not necessarily. depends on how the daemon is written. for instance,
my bind9 chroot has absolutely zero anything in violation with the
FHS!
but i see your point. it's a flaw in the policy/FHS though, i think.
--
martin; (greetings from the heart of the sun.)
\ echo mailto: !#^.*|tr * mailto:; net@madduck
you work very hard. don't try to think as well.
msg05981/pgp0.pgp
Description: PGP signature
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.03.07.1054
+0100]:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
me too...
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
not necessarily. depends on how the daemon is written. for instance,
my bind9 chroot has absolutely zero anything in violation with the
FHS!
but i see your point. it's a flaw in the policy/FHS though, i think.
--
martin; (greetings from the heart of the sun.)
\ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
you work very hard. don't try to think as well.
pgpZGNwJx8Y0H.pgp
Description: PGP signature
Re: default security
On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.
Regards
Javi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Javier Fernández-Sanguino Peña wrote:
On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS
He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:
http://www.pathname.com/fhs/
and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.
Regards
Javi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at: 5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.
Regards
Javi
Re: default security
Javier Fernández-Sanguino Peña wrote:
On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
how would it break policy?
(sorry, catching up with posts)
Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS
He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:
http://www.pathname.com/fhs/
and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.
Regards
Javi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at: 5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.
Re: default security
On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: [snip] Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) [snip] The above link contains the following: FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified. My opinion is that things that need to be writable should be owned by the user that runs named, but everything else should be owned by root. i.e. secondary zones etc., should be owned by the user that runs named. If you're doing dynamic DNS, the primary zones will also need to be writable. named.conf (and primary zones if you're not doing dynamic DNS) should be owned by root and not writable by named. This way, if there's a bind exploit, an attacker can't corrupt your zone files or config file (except for the secondary zones.) Of course, they may still be able to make the DNS server serve incorrect information, but at least it's another hurdle for them to jump over. -- Michael Wood [EMAIL PROTECTED]
default security
I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Tarjei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
I'd agree with your comments. I being looking at OpenBSD (for various reasons) and the default setup is reasonable secure (there are still some things left on , which supprised me). Not sure if Debian needs to go as far as OpenBSD but I think that it is a good referance base Jon --- Tarjei [EMAIL PROTECTED] wrote: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Tarjei __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Debian, unlike RedHat or Mandrake provides and gives support for Bastille Linux. Even if the default setup is quite good (security-wise) it can easily be made even better. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). BTW, Bastille does have modules for chrooting services (it has one for Bind) that can be selected when hardening the system. You could also help having Bastille's module (for Bind) adapted to Debian (I have not had time to do so myself) Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.01.15.1316 +0100]: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) well, first of all, this document refers to a bug, #50013 (to which this is CCd). in the bug, the argument comes up that opinions differ from running bind non-root. but a chroot jail is advised. i'd love to know just why you'd ever run bind as root, even in a jail. if i have root rights in a jail, i'll break out of the jail within minutes (e.g. [1]). second, why would you *need* bind running as root? and thirdly, please check the threads at [2] and [3] if you are interested in a discussion on bind9 and chroot. One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. running non-root *and* chrooting. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). how would it break policy? 1. http://www.bpfh.net/simes/computing/chroot-break.html 2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html 3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck above all, we should not wish to divest our existence of its rich ambiguity. -- nietzsche msg05281/pgp0.pgp Description: PGP signature
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: [snip] Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) [snip] The above link contains the following: FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified. My opinion is that things that need to be writable should be owned by the user that runs named, but everything else should be owned by root. i.e. secondary zones etc., should be owned by the user that runs named. If you're doing dynamic DNS, the primary zones will also need to be writable. named.conf (and primary zones if you're not doing dynamic DNS) should be owned by root and not writable by named. This way, if there's a bind exploit, an attacker can't corrupt your zone files or config file (except for the secondary zones.) Of course, they may still be able to make the DNS server serve incorrect information, but at least it's another hurdle for them to jump over. -- Michael Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Debian, unlike RedHat or Mandrake provides and gives support for Bastille Linux. Even if the default setup is quite good (security-wise) it can easily be made even better. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). BTW, Bastille does have modules for chrooting services (it has one for Bind) that can be selected when hardening the system. You could also help having Bastille's module (for Bind) adapted to Debian (I have not had time to do so myself) Regards Javi
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.01.15.1316 +0100]: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) well, first of all, this document refers to a bug, #50013 (to which this is CCd). in the bug, the argument comes up that opinions differ from running bind non-root. but a chroot jail is advised. i'd love to know just why you'd ever run bind as root, even in a jail. if i have root rights in a jail, i'll break out of the jail within minutes (e.g. [1]). second, why would you *need* bind running as root? and thirdly, please check the threads at [2] and [3] if you are interested in a discussion on bind9 and chroot. One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. running non-root *and* chrooting. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). how would it break policy? 1. http://www.bpfh.net/simes/computing/chroot-break.html 2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html 3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] above all, we should not wish to divest our existence of its rich ambiguity. -- nietzsche pgpPhGfngiiHZ.pgp Description: PGP signature
Re: default security
Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. 2. Go through the 10 highest and make sure they follow secure practies like libsafe. 3. Support security in these servers also for testing and unstable. rant I think it would be worthwhile to rethink the philosophy of debian-stable. Instead of saying the next version of debian is stable when all it's packages are stable, how about defining a stable version of each package, and saying that stable is a dynamic target. In the age of highspeed conections, most most people could then install debian over the 'net instead of the install cd's. /rant I apoligize to all the people reading this list for filling it with rants. Will stop now. Tarjei
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/
