RE: [SECURITY] [DSA 3057-2] libxml2 regression update
Darn it, we need this, but not during the day, just soon. We're using libxml2 to drive some important stuff, but it's all outgoing stuff, as far as I know. Charlie -Original Message- From: Salvatore Bonaccorso [mailto:car...@debian.org] Sent: Tuesday, April 07, 2015 1:59 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3057-2] libxml2 regression update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-3057-2 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso April 07, 2015 http://www.debian.org/security/faq - - Package: libxml2 Debian Bug : 774358 The update for libxml2 issued as DSA-3057-1 caused regressions due to an incomplete patch to address CVE-2014-3660. Updated packages are available to address this problem. For reference the original advisory text follows. Sogeti found a denial of service flaw in libxml2, a library providing support to read, modify and write XML and HTML files. A remote attacker could provide a specially crafted XML file that, when processed by an application using libxml2, would lead to excessive CPU consumption (denial of service) based on excessive entity substitutions, even if entity substitution was disabled, which is the parser default behavior. (CVE-2014-3660) For the stable distribution (wheezy), this problem has been fixed in version 2.8.0+dfsg1-7+wheezy4. We recommend that you upgrade your libxml2 packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJVJCi+AAoJEAVMuPMTQ89EwvoQAJ3XjEknlEmqjvr6N+W45k4A R1F/51r1M17GpqFmhrnqcHTa0nTFgrQhcNgkKfF68GFrjr/jKyoC0HKjbwFl6j6a Zx0KrcWn39e/oM9DFYV9fcfkQKwsVQPqYsvp4PKVxMKRGLE7Ke21OYQdHxtUxYDy HHL2mlgMWe/k5+T9qvJZVFe6HZrleIkGP8SSWkzQbFKOVBIJk2RyVrbUrxHmUi+j KjhJBf+6VgT62+YprJGLtgPN/nitqoF9Zfk3qT2sgDyPAkdHV26S1vAPrlPK5KTN CwxcfZQShcQiQOsV3If6InSG97evAsMV3TbxAwaPBUTxNCLf07Z40Zlbvf7XvXyg apJ4TmV2cDY1f2g9hfHxgLwt8FWSosrZbrQi4a0QMFIb8Idf4YTOobDjy2kNio9l IrFumsvX1+tSdPYOOq37qKhfkRT4L0+aPsHOAn/6lfOz5DSGATvJ17yHvjYUnq2w 2gWE0VzOYG+iz8DtuJb79GvHUZGgbKjOMOCSbTa8udSQ+Ez6YjdgsGTw+PxIsF4h CxgFlQUOhozoGwZ5ryodBLWLPk38SDD/DAeGicSz87ZxIr2T6JLV+vFBEh0xTiJ4 Q4qPcxDCJrzUKmUkTSyCuBill4S9yz2NmbSIou9qdxF2r186S5YJqCUhlXAoTNF+ 6PqavMqfFYzb1VtDBjZ/ =b9Wb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yfyhw-000509...@master.debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blupr03mb341660701545d552316f521e0...@blupr03mb341.namprd03.prod.outlook.com
RE: [SECURITY] [DSA 3094-1] bind9 security update
Please disregard my prior message. It was directed to the incorrect recipients. My apologies for any inconvenience that might have been caused. -Original Message- From: Charles Stewart Sent: Monday, December 08, 2014 5:57 PM To: 'debian-security@lists.debian.org'; debian-security-annou...@lists.debian.org Subject: RE: [SECURITY] [DSA 3094-1] bind9 security update We don't run the bind9 server on production appliances, but we do pull in the bind9 client libs and tools, so that will need updating. -Original Message- From: Giuseppe Iuculano [mailto:iucul...@debian.org] Sent: Monday, December 08, 2014 4:43 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3094-1] bind9 security update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-3094-1 secur...@debian.org http://www.debian.org/security/ Giuseppe Iuculano December 08, 2014 http://www.debian.org/security/faq - - Package: bind9 CVE ID : CVE-2014-8500 It was discovered that BIND, a DNS server, is prone to a denial of service vulnerability. By making use of maliciously-constructed zones or a rogue server, an attacker can exploit an oversight in the code BIND 9 uses to follow delegations in the Domain Name Service, causing BIND to issue unlimited queries in an attempt to follow the delegation. This can lead to resource exhaustion and denial of service (up to and including termination of the named server process.) For the stable distribution (wheezy), this problem has been fixed in version 1:9.8.4.dfsg.P1-6+nmu2+deb7u3. For the upcoming stable distribution (jessie), this problem will be fixed soon. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your bind9 packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhhtUAAoJEI9hzo2UfbETZNgQAK3cYJpGVfcD03AEU5KEkXbO rUor18BYRz6lCPSeLqIuF0OHR+ForpgV0t1CZ2mtexr3MSgve/LZn1LH5/YnYCLT 2A3UEtNgi7hzChbgQbWTLXTGzn1eOMxq1lS/pS40h0eLWrbKO8DIA+YiLzVm6G4a rBqHuF+7CoBcRLckk3G2pu+XUFH7SrSFURu8537/ihLqOU7s1vf26G79XmDxFp1m DHhqJ4A/qRTVwBcTaa7nXkQ3YZ1dNFjiSdq44i8N2NZgXhqPyfkfIEWmYI4pSVHi rWpW8j8K2EagbovTUcEYG4OW0P+R06oYNT3QP9RaDiGfEqge+L8gb+RJIZFkmh2o RDdpg3M4B8OZ9JVl/5x4Jdf6LUpfBe1UtAawNC8Fh7B/Xajgsr7mF7DsTBNDSOh9 5BhhSuZrSw2ZVU4rvC4g06lA6lq6GfXzwY8S0M9Mo3BeqvIr2L6BzX7ONUpmBx3n OAvbTFtaB2LZMoP2JVaa9wMmb2F5c5PMVRphaP+2AxP3KSLOYOCLoEv2gg/6udmU PC48Pyl2mm5TzSM7URZEP1lqx/lasdjg/XKfq/SkT7ZRXZqdd/aDy1M4R3RBNzWw dMH+vUHS4qdI2wxKrLkcOQjlQtqHh6+8fWSFb58OLEm7gJB9rMjtFvzcs4nvWiyh 12hvYBbyAjb6ovdvfYsP =b2o8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208214244.ga21...@sd6-work.iuculano.it -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6E5DEE2EE1D461478BC8045CC3D9C77B2AF68D8B@LCHQEX03.lancope.local
RE: [SECURITY] [DSA 3094-1] bind9 security update
We don't run the bind9 server on production appliances, but we do pull in the bind9 client libs and tools, so that will need updating. -Original Message- From: Giuseppe Iuculano [mailto:iucul...@debian.org] Sent: Monday, December 08, 2014 4:43 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3094-1] bind9 security update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-3094-1 secur...@debian.org http://www.debian.org/security/ Giuseppe Iuculano December 08, 2014 http://www.debian.org/security/faq - - Package: bind9 CVE ID : CVE-2014-8500 It was discovered that BIND, a DNS server, is prone to a denial of service vulnerability. By making use of maliciously-constructed zones or a rogue server, an attacker can exploit an oversight in the code BIND 9 uses to follow delegations in the Domain Name Service, causing BIND to issue unlimited queries in an attempt to follow the delegation. This can lead to resource exhaustion and denial of service (up to and including termination of the named server process.) For the stable distribution (wheezy), this problem has been fixed in version 1:9.8.4.dfsg.P1-6+nmu2+deb7u3. For the upcoming stable distribution (jessie), this problem will be fixed soon. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your bind9 packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhhtUAAoJEI9hzo2UfbETZNgQAK3cYJpGVfcD03AEU5KEkXbO rUor18BYRz6lCPSeLqIuF0OHR+ForpgV0t1CZ2mtexr3MSgve/LZn1LH5/YnYCLT 2A3UEtNgi7hzChbgQbWTLXTGzn1eOMxq1lS/pS40h0eLWrbKO8DIA+YiLzVm6G4a rBqHuF+7CoBcRLckk3G2pu+XUFH7SrSFURu8537/ihLqOU7s1vf26G79XmDxFp1m DHhqJ4A/qRTVwBcTaa7nXkQ3YZ1dNFjiSdq44i8N2NZgXhqPyfkfIEWmYI4pSVHi rWpW8j8K2EagbovTUcEYG4OW0P+R06oYNT3QP9RaDiGfEqge+L8gb+RJIZFkmh2o RDdpg3M4B8OZ9JVl/5x4Jdf6LUpfBe1UtAawNC8Fh7B/Xajgsr7mF7DsTBNDSOh9 5BhhSuZrSw2ZVU4rvC4g06lA6lq6GfXzwY8S0M9Mo3BeqvIr2L6BzX7ONUpmBx3n OAvbTFtaB2LZMoP2JVaa9wMmb2F5c5PMVRphaP+2AxP3KSLOYOCLoEv2gg/6udmU PC48Pyl2mm5TzSM7URZEP1lqx/lasdjg/XKfq/SkT7ZRXZqdd/aDy1M4R3RBNzWw dMH+vUHS4qdI2wxKrLkcOQjlQtqHh6+8fWSFb58OLEm7gJB9rMjtFvzcs4nvWiyh 12hvYBbyAjb6ovdvfYsP =b2o8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208214244.ga21...@sd6-work.iuculano.it -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6E5DEE2EE1D461478BC8045CC3D9C77B2AF68CB9@LCHQEX03.lancope.local
FW: CVE-2011-2147 is a dud, was Re:World writable pid and lock files.
All, Looping in MITRE, as they are responsible for the assignment of CVEs. If it is determined this CVE has been assigned in error, updates to the NVD data feeds will be occur within 24 hours of MITRE updates. Thanks you, Chuck Wergin National Vulnerability Database nvd.nist.gov -Original Message- From: helpermn [mailto:helpe...@gmail.com] Sent: Tuesday, May 31, 2011 4:56 AM To: Paul Wouters Cc: nvd; debian-security@lists.debian.org; annou...@openswan.org; supp...@xelerance.com Subject: Re: CVE-2011-2147 is a dud, was Re:World writable pid and lock files. On 2011-05-30 at 23:26 Paul Wouters wrote: >> >>* To: debian-security@lists.debian.org >>* Subject: World writable pid and lock files. >>* From: helpermn >>* Date: Tue, 10 May 2011 15:40:22 +0200 >>* Message-id: <05578bff-44fc-41b3-9e8e-c11b5b9a6...@gmail.com> >> Hello! >> I imagine why files listed below have 666 file mode bits set: >> /var/run/checkers.pid >> /var/run/vrrp.pid >> /var/run/keepalived.pid >> /var/run/starter.pid >> /var/lock/subsys/ipsec >> Files are created during startup of ipsec (pluto) and keepalived >> deamons. >> I think thar leaving them world writable is security hole. For >> example delete or change of its content could confuses monit >> watching them running and restarting when they die. >> Regards. >> -- >> helpermn > > It seems this report got turned into a CVE for Openswan, CVE-2011-2147 > > http://www.securityfocus.com/bid/47958/info > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2147 > > If debian is still shipping openswan-2.2 unpatched anywhere (released > January 2005) this could be a problem, albeit an extremely minor > one compared to the actual two CVE issues that have come up in > openswan > since then. We hope that any openswan-2.2 version that is in active > use > has at least gotten some serious looking at based on the security > releases > that have since been made. > > openswan 2.6.x on debian/ubuntu and fedora/rhel/centos create a read- > only > file in /var/locl/subsys. > > If someone finds an issue that is actually a security issue, and they > deem it worthy of a CVE release, we strongly encourage those people to > contact us beforehand so we can do a proper responsible vulnerability > disclosure. We also strongly recommend that the CVE people at least > attempt > to make an attempt to contact a vendor before releasing > vulnerabilities > to the public. We don't bite, honest! > > It looks as if someone or some company was in need of reaching their > CVE quota of the month. It would be a shame if future CVE > announcements > would get ignored because of too many CVE releases on 6 year old > software > releases. > > Paul Wouters I see some mistakes. In stable Debian realease and what I use: strongswan 4.4.1-5.1 (newest release is 4.5.2 - project homepage) keepalived 1.1.20-1 (newest release 1.2.2 - project homepage) So problem is similar but it is not old openswan-2.2 about which we can read in CVE. I don't know who/how/why did the mistake but the problem which I have reported here (Debian security group) still exists. Any suggestions? Regards. -- helpermn -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d7a0423e5e193f40be6e94126930c4930878fb5...@mbcluster.xchange.nist.gov
Re: [Debian-med-packaging] Bug#496366: Bug#496366: Bug#496366: The possibility of attack with the help of symlinks in some Debian packages
tag 496366 forwarded Kazutaka Katoh <[EMAIL PROTECTED]> thanks Hi all, I forwarded the patch solving the problem to the upstream author. I would prefer if I could include a note that the patch was accepted upstream if possible. How long would you recommend to wait before uploading ? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-med-packaging] Bug#496366: The possibility of attack with the help of symlinks in some Debian packages
tag 496366 help thanks Le Sun, Aug 24, 2008 at 10:05:28PM +0400, Dmitry E. Oboukhov a écrit : > Package: mafft > Severity: grave > > In some packages I've discovered scripts with errors which may be used > by a user for damaging important system files or user's files. Hi all, I have not followed the discussions on -devel closely. What is the relevance of this bug for the releasability of the package? Upstream is already at a much higher version number and I am not able to solve the prolem by myself. Since the vulnerabiilty can only be exploited by other local users, and since mafft is a scientific software either used on personnal computers or on scientific workstations in trusted environments, can I ignore the bug for Lenny and work with Upsteam on a fix in the latest release? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489678: tree-puzzle: Uses a local copy of libsprng.
Package: tree-puzzle Version: 5.2-3 Severity: important Dear all, tree-puzzle in Debian is built against a local copy of the SPRNG library, and this is against best pactices and recommendations of the security team. However, tree-puzzle uses version 1 and Debian provides version 2. So close to the freeze, I do not know if it is wise to make a change now. Your feedback is most welcome. http://packages.qa.debian.org/t/tree-puzzle.html http://packages.qa.debian.org/s/sprng.html anx159《debian》$ apt-cache rdepends libsprng2 libsprng2 Reverse Depends: r-cran-rsprng libsprng2-doc libsprng2-dev Have a nice day, -- Charles Plessy, Debian-Med packaging team, Tsurumi, Kanagawa, Japan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 2.6.25-1-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tree-puzzle depends on: ii libc6 2.7-10 GNU C Library: Shared libraries Versions of packages tree-puzzle recommends: ii tree-puzzle-doc 5.2-4 Reconstruction of phylogenetic tre -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JCE Code Signing Certificate
> > This is a big field which needs even bigger investigation. The free > > runtimes can load them but signed jars are still not supported (or was > > this fixed lately...). Your best action would be to just test it with > > kaffe or gcj or whatever and report any bugs you find. > > In the meantime, it occurred to me that the certified key (including > the private key) would have to be included in the source package, > otherwise the package would fail to build from source. > > While I see nothing in Sun's form that requires us to keep the private > key secret, publishing it still not be such a good idea. The key must be kept secret, otherwise it can't be trusted (i.e. people could maliciously modify the code, and then sign their modifications). How to best architect this into Debian is another question... Charles -- Substitutes Can let you down Quicker Than a Strapless gown Burma-Shave http://burma-shave.org/jingles/1955/substitutes signature.asc Description: Digital signature
Re: [SECURITY] [DSA 847-1] New dia packages fix arbitrary code execution
Out of office until 17 Oct. Please contact [EMAIL PROTECTED] instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 846-1] New cpio packages fix several vulnerabilities
Out of office until 17 Oct. Please contact [EMAIL PROTECTED] instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JCE Code Signing Certificate
> > In order to be trusted, the security provider must be signed with a > > key that was certified by the JCE Code Signing Certification > > Authority (see Step 5 of the document above). > > So why can't we ship trusted root certificates for a Debian Code > Signing Certification Authority, or trust everything which is present > in the file system? Your first proposition sounds reasonable at first glance, though I would like some feedback from others who are more familiar with the free JVMs that ship with Java. > I have the strong suspicion that this certificate just asserts that > you have signed the CSR form and promised to comply with U.S. export > regulations, and nothing else. Maybe this was the result of a deal > between BXA/BIS and Sun which permitted Sun to export their > implementation. We don't need to follow such a procedure because > Debian has different means to comply with the regulations, and we do > not distribute Sun's implementation, AFAIK. Though we don't distribute Sun's implementation, java-package provides a straightforward way to insall Sun's installation on a Debian machine. Further, due to what appears to be a Classpath bug, no free JVM that we do ship is able to pass all of the BouncyCastle regression tests (which is why BouncyCastle is currently in contrib). Does anyone from debian-java know how the free JVMs deal with security providers? Charles -- Always remember On any trip Keep two things Within your grip Your steering wheel and Burma-Shave http://burma-shave.org/jingles/1940/always_remember signature.asc Description: Digital signature
Re: JCE Code Signing Certificate
> > Can someone please comment on how we should proceed to obtain a JCE Code
> > Signing Certificate for Debian?
>
> Why can't we just install a trusted certificate in our own packages?
>
> It's not clear to me who should own the private key corresponding to
> the certificate, either. Perhaps you could explain why this
> certificate is needed? Hopefully, the rest follows from that.
Well, I may not entirely understand your question, but here is my
understanding of the situation, as supported by the document How to
Implement a Provider for the JavaTM Cryptography Extension[1].
1.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/HowToImplAJCEProvider.html
You should definitely read the introduction of that document. I started
to cut and paste, but there is just too much relevant information. To
summarize, JCE provides a modular framework whereby various security
"providers" can implement generic security algorithms, and make them
available by name, independent of any knowledge of the provider where
they are coming from.
For example, I could issue the following call to obtain a Signature
instance using a certain algorithm, fit for use in creating
cryptographic signatures, by the following call:
Signature sig = Signature.getInstance("MD5withRSA");
This will result in a search of the security providers in
$JAVA_HOME/lib/security/java.security until a provider is found who
provides an implementation of the requested algorithm. In order to be
trusted, the security provider must be signed with a key that was
certified by the JCE Code Signing Certification Authority (see Step 5 of
the document above).
The upstream distribution of BouncyCastle, for example, is signed by
such a code-signing certificate, but instead of trusting them we want to
build the code ourselves, which means that we in turn need to sign it
ourselves.
Does that clarify things a little?
Charles
--
From New York town
To Pumpkin Holler
Still
Half a pound
For half a dollar
Burma-Shave
No price increase
http://burma-shave.org/jingles/1948/from_new_york
signature.asc
Description: Digital signature
Re: JCE Code Signing Certificate
I should also point out that this JCE Code Signing Certificate is necessary not only to allow libbcprov-java to be used as a trusted security provider, but also for me to package bcmail, bctsp, and bcpg which are also part of Bouncy Castle. I can currently build all of them, but the regression tests fail as the resulting jars need to be signed. Can someone please comment on how we should proceed to obtain a JCE Code Signing Certificate for Debian? thanks, Charles -Original Message- > From: Charles Fry <[EMAIL PROTECTED]> > Subject: JCE Code Signing Certificate > Date: Fri, 30 Sep 2005 13:04:43 -0400 > To: debian-security@lists.debian.org > Cc: debian-java@lists.debian.org > Old-Return-Path: <[EMAIL PROTECTED]> > > Now that BouncyCastle[1] has been packaged for Debian[2], it is time for > us to move forward with Arnaud's suggestion[3] that we obtain a JCE Code > Signing Certificate[4] for Debian, in order to vouch for this and other > JCE Security Providers that Debian may provide. > > The process is fairly straight-forward, as outlined in [4]. Having no > previous experience with anything similar, I assume that this should be > handled by the Security Team. > > I am hoping that someone on one of these lists will know the proper way > to proceed from here. :-) > > cheers, > Charles > >1. http://www.bouncycastle.org/ >2. http://packages.debian.org/unstable/libs/libbcprov-java >3. http://lists.debian.org/debian-java/2004/04/msg00014.html >4. > http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/HowToImplAJCEProvider.html#Step%205 > > -- > Why does a chicken > Cross the street? > She sees a guy > She'd like to meet > He uses > Burma-Shave > http://burma-shave.org/jingles/1945/why_does_a -- Within this vale Of toil And sin Your head grows bald But not your chin -- Use Burma-Shave http://burma-shave.org/jingles/1943/within_this_vale signature.asc Description: Digital signature
JCE Code Signing Certificate
Now that BouncyCastle[1] has been packaged for Debian[2], it is time for us to move forward with Arnaud's suggestion[3] that we obtain a JCE Code Signing Certificate[4] for Debian, in order to vouch for this and other JCE Security Providers that Debian may provide. The process is fairly straight-forward, as outlined in [4]. Having no previous experience with anything similar, I assume that this should be handled by the Security Team. I am hoping that someone on one of these lists will know the proper way to proceed from here. :-) cheers, Charles 1. http://www.bouncycastle.org/ 2. http://packages.debian.org/unstable/libs/libbcprov-java 3. http://lists.debian.org/debian-java/2004/04/msg00014.html 4. http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/HowToImplAJCEProvider.html#Step%205 -- Why does a chicken Cross the street? She sees a guy She'd like to meet He uses Burma-Shave http://burma-shave.org/jingles/1945/why_does_a signature.asc Description: Digital signature
GET CD AND DOWNLOADS, all software under $99-$15
Welcome to VIP Quality Software. http://bgvt.d2haguvoa5v2aed.recoolhhkld.info We think in generalities, but we live in detail. The most profound statements are often said in silence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Christian Hammers <[EMAIL PROTECTED]> écrivait (wrote) : > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > > > Is there an emergency patch/workaround for this, if disabling ssh is not > > an option? Are systems with Privilege Separation affected? > > The new version has already been installed. This was quick. Good work, > security team. Same for most boxes here but there seem to be a versioning conflict between security update and woody proposed update : apt-cache policy ssh ssh: Installed: 1:3.4p1-1.woody.1 Candidate: 1:3.4p1-1.woody.1 Version Table: *** 1:3.4p1-1.woody.1 0 500 ftp://ftp.u-picardie.fr woody-proposed-updates/main Packages 100 /var/lib/dpkg/status 1:3.4p1-1.1 0 500 http://security.debian.org woody/updates/main Packages 1:3.4p1-1 0 500 ftp://ftp.u-picardie.fr woody/main Packages I will force the security.debian.org version to apply but I think people should be aware of the risq of using woody/updates and maybe one of the too should be renumbered. Jean Charles
Re: [d-security] Re: ssh vulnerability in the wild
Christian Hammers <[EMAIL PROTECTED]> écrivait (wrote) : > On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote: > > On Tue, 16 Sep 2003, Alexander Neumann wrote: > > > > > According to Wichert, the security team is already working on an update. > > > > Is there an emergency patch/workaround for this, if disabling ssh is not > > an option? Are systems with Privilege Separation affected? > > The new version has already been installed. This was quick. Good work, > security team. Same for most boxes here but there seem to be a versioning conflict between security update and woody proposed update : apt-cache policy ssh ssh: Installed: 1:3.4p1-1.woody.1 Candidate: 1:3.4p1-1.woody.1 Version Table: *** 1:3.4p1-1.woody.1 0 500 ftp://ftp.u-picardie.fr woody-proposed-updates/main Packages 100 /var/lib/dpkg/status 1:3.4p1-1.1 0 500 http://security.debian.org woody/updates/main Packages 1:3.4p1-1 0 500 ftp://ftp.u-picardie.fr woody/main Packages I will force the security.debian.org version to apply but I think people should be aware of the risq of using woody/updates and maybe one of the too should be renumbered. Jean Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DHCP
Actually, we have to create a host name when we register out MAC addresses. This allows the same host name to be resolved to our IP. - Chuck Haines GDC Systems Administrator Infinity Complex Developer WPILA Lab Manager - AIM: CyberGrex ICQ: 3707881 Yahoo: CyberGrex_27 Cell: (410) 610-6343. - "Geek by nature, Linux by choice." -Original Message- From: Hanasaki JiJi [mailto:[EMAIL PROTECTED] Sent: Monday, October 28, 2002 8:39 PM To: Haines, Charles Allen Cc: debian-security@lists.debian.org Subject: Re: DHCP Too bad there is no way to do a secure handshake w/ an id/password or even SecureID cards. Any way to make the same host name resolve to your IP irreguardless of what IP is allocted to your box by dhcp? Haines, Charles Allen wrote: > Well here at WPI, we have to register each and every MAC address that > we wish to use on campus. If your MAC address isn't registered, you > get no network. It works the same way with wireless. And to the best > of my knowledge, DHCP is used. > > - > Chuck Haines > GDC Systems Administrator > Infinity Complex Developer > WPILA Lab Manager > - > AIM: CyberGrex > ICQ: 3707881 > Yahoo: CyberGrex_27 > Cell: (410) 610-6343. > - > "Geek by nature, Linux by choice." > > > > -Original Message- > From: Jones, Steven [mailto:[EMAIL PROTECTED] > Sent: Monday, October 28, 2002 8:06 PM > To: 'Stewart James'; debian-security@lists.debian.org > Subject: RE: DHCP > > > ik campus > > ik > > ik > > so zilch physical security > > you didnt say this in your earlier post, this has severe security > implications, in fact Id suggest you'd be a danger to the internet > > I'd suggest a letter to the ppl that want this and tell them of the > severe secuity implications of what they want. > > you'd be a hackers/spammers dream...sit in the carpark with a > laptop and wi-fi and spam the world. > > cant use static mapping of IPs to MACs.to many unknown MACs, well > you can > > request each person registers thier machine with the helldesk and gets > a static IP given out locked to the MAC address they provide. Run > arpwatch to look for illegal connections > > We are trialing wi-fi city wide, the wi-fi lan is behind a firewall > and are blocking port 25, then opening up ports as requested based on > merits. > > DHCP is the least of your worries... > > This is not really a debian security issue but a general security > issue, I would suggest you get a security policy written and get it > agreed with "management". its your best set of defences from getting > screwed over when something goes wrong. Also writing this and getting > it agreed will give you time to research and get up to speed. > > Also the DHCP server should have a firewall of its own at the very > least. > > It suggests careful planning is needed before implimentation, possibly > a campus wide audit after a policy is agreed (you audit against the > policy) > > regards > > Im writing a policy myself and its taking a while.it will be posted on > the Internet once done for free use and comment. The debian security > howto is good, if you have not read it please do. > > I'd split campus network up into a trusted and untrusted LAN )incl > wi-fi network), the untrusted LAN should be treated as the Internet ie > a danger zone and firewalled... > > i could go on and on..i suspect you have a lot to do.. > > regards > > Steven > > > > -Original Message- > From: Stewart James [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 29 October 2002 12:53 > To: debian-security@lists.debian.org > Subject: RE: DHCP > > > > I had the very same thoughts, being a university you can imagine what > physical security is like, plus management wants to give students the > ability to walk on campus and plugin, plus start wireless services > too. > > From what people have sent back from my question, I don;t think we > will be any worse of security wise as far as moving to DHCP will go. > > Thanks for the various responses, if someone still thinks of a big > issue I would love to hear it. > > Cheers, > > Stewart > > On Tue, 29 Oct 2002, Jones, Steven wrote: > > >>Date: Tue, 29 Oct 2002 12:19:06 +130
RE: DHCP
Well here at WPI, we have to register each and every MAC address that we wish to use on campus. If your MAC address isn't registered, you get no network. It works the same way with wireless. And to the best of my knowledge, DHCP is used. - Chuck Haines GDC Systems Administrator Infinity Complex Developer WPILA Lab Manager - AIM: CyberGrex ICQ: 3707881 Yahoo: CyberGrex_27 Cell: (410) 610-6343. - "Geek by nature, Linux by choice." -Original Message- From: Jones, Steven [mailto:[EMAIL PROTECTED] Sent: Monday, October 28, 2002 8:06 PM To: 'Stewart James'; debian-security@lists.debian.org Subject: RE: DHCP ik campus ik ik so zilch physical security you didnt say this in your earlier post, this has severe security implications, in fact Id suggest you'd be a danger to the internet I'd suggest a letter to the ppl that want this and tell them of the severe secuity implications of what they want. you'd be a hackers/spammers dream...sit in the carpark with a laptop and wi-fi and spam the world. cant use static mapping of IPs to MACs.to many unknown MACs, well you can request each person registers thier machine with the helldesk and gets a static IP given out locked to the MAC address they provide. Run arpwatch to look for illegal connections We are trialing wi-fi city wide, the wi-fi lan is behind a firewall and are blocking port 25, then opening up ports as requested based on merits. DHCP is the least of your worries... This is not really a debian security issue but a general security issue, I would suggest you get a security policy written and get it agreed with "management". its your best set of defences from getting screwed over when something goes wrong. Also writing this and getting it agreed will give you time to research and get up to speed. Also the DHCP server should have a firewall of its own at the very least. It suggests careful planning is needed before implimentation, possibly a campus wide audit after a policy is agreed (you audit against the policy) regards Im writing a policy myself and its taking a while.it will be posted on the Internet once done for free use and comment. The debian security howto is good, if you have not read it please do. I'd split campus network up into a trusted and untrusted LAN )incl wi-fi network), the untrusted LAN should be treated as the Internet ie a danger zone and firewalled... i could go on and on..i suspect you have a lot to do.. regards Steven -Original Message- From: Stewart James [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 October 2002 12:53 To: debian-security@lists.debian.org Subject: RE: DHCP I had the very same thoughts, being a university you can imagine what physical security is like, plus management wants to give students the ability to walk on campus and plugin, plus start wireless services too. >From what people have sent back from my question, I don;t think we will be any worse of security wise as far as moving to DHCP will go. Thanks for the various responses, if someone still thinks of a big issue I would love to hear it. Cheers, Stewart On Tue, 29 Oct 2002, Jones, Steven wrote: > Date: Tue, 29 Oct 2002 12:19:06 +1300 > From: "Jones, Steven" <[EMAIL PROTECTED]> > To: 'Stewart James' <[EMAIL PROTECTED]>, > debian-security@lists.debian.org > Subject: RE: DHCP > Resent-Date: Mon, 28 Oct 2002 17:24:16 -0600 (CST) > Resent-From: debian-security@lists.debian.org > > u could set dhcp to give out a fixed address dependant on a mac > address, this would stop just anybody plugging a box into a network, > if your network > is physically secure then thats not a worry. (a cat5 jack in reception > or some other public place is dodgy) > > Otherwise dhcp makes life easier...its the only way to manage a decent sized > network. > > :) > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DHCP
Actually, we have to create a host name when we register out MAC addresses. This allows the same host name to be resolved to our IP. - Chuck Haines GDC Systems Administrator Infinity Complex Developer WPILA Lab Manager - AIM: CyberGrex ICQ: 3707881 Yahoo: CyberGrex_27 Cell: (410) 610-6343. - "Geek by nature, Linux by choice." -Original Message- From: Hanasaki JiJi [mailto:hanasaki@;hanaden.com] Sent: Monday, October 28, 2002 8:39 PM To: Haines, Charles Allen Cc: [EMAIL PROTECTED] Subject: Re: DHCP Too bad there is no way to do a secure handshake w/ an id/password or even SecureID cards. Any way to make the same host name resolve to your IP irreguardless of what IP is allocted to your box by dhcp? Haines, Charles Allen wrote: > Well here at WPI, we have to register each and every MAC address that > we wish to use on campus. If your MAC address isn't registered, you > get no network. It works the same way with wireless. And to the best > of my knowledge, DHCP is used. > > - > Chuck Haines > GDC Systems Administrator > Infinity Complex Developer > WPILA Lab Manager > - > AIM: CyberGrex > ICQ: 3707881 > Yahoo: CyberGrex_27 > Cell: (410) 610-6343. > - > "Geek by nature, Linux by choice." > > > > -Original Message- > From: Jones, Steven [mailto:sjones08@;eds.com] > Sent: Monday, October 28, 2002 8:06 PM > To: 'Stewart James'; [EMAIL PROTECTED] > Subject: RE: DHCP > > > ik campus > > ik > > ik > > so zilch physical security > > you didnt say this in your earlier post, this has severe security > implications, in fact Id suggest you'd be a danger to the internet > > I'd suggest a letter to the ppl that want this and tell them of the > severe secuity implications of what they want. > > you'd be a hackers/spammers dream...sit in the carpark with a > laptop and wi-fi and spam the world. > > cant use static mapping of IPs to MACs.to many unknown MACs, well > you can > > request each person registers thier machine with the helldesk and gets > a static IP given out locked to the MAC address they provide. Run > arpwatch to look for illegal connections > > We are trialing wi-fi city wide, the wi-fi lan is behind a firewall > and are blocking port 25, then opening up ports as requested based on > merits. > > DHCP is the least of your worries... > > This is not really a debian security issue but a general security > issue, I would suggest you get a security policy written and get it > agreed with "management". its your best set of defences from getting > screwed over when something goes wrong. Also writing this and getting > it agreed will give you time to research and get up to speed. > > Also the DHCP server should have a firewall of its own at the very > least. > > It suggests careful planning is needed before implimentation, possibly > a campus wide audit after a policy is agreed (you audit against the > policy) > > regards > > Im writing a policy myself and its taking a while.it will be posted on > the Internet once done for free use and comment. The debian security > howto is good, if you have not read it please do. > > I'd split campus network up into a trusted and untrusted LAN )incl > wi-fi network), the untrusted LAN should be treated as the Internet ie > a danger zone and firewalled... > > i could go on and on..i suspect you have a lot to do.. > > regards > > Steven > > > > -Original Message- > From: Stewart James [mailto:stewart.james@;vu.edu.au] > Sent: Tuesday, 29 October 2002 12:53 > To: [EMAIL PROTECTED] > Subject: RE: DHCP > > > > I had the very same thoughts, being a university you can imagine what > physical security is like, plus management wants to give students the > ability to walk on campus and plugin, plus start wireless services > too. > > From what people have sent back from my question, I don;t think we > will be any worse of security wise as far as moving to DHCP will go. > > Thanks for the various responses, if someone still thinks of a big > issue I would love to hear it. > > Cheers, > > Stewart > > On Tue, 29 Oct 2002, Jones, Steven wrote: > > >>Date: Tue, 29 Oct 2002 12:19:06 +1300 >>From: "Jones, Steven&
RE: DHCP
Well here at WPI, we have to register each and every MAC address that we wish to use on campus. If your MAC address isn't registered, you get no network. It works the same way with wireless. And to the best of my knowledge, DHCP is used. - Chuck Haines GDC Systems Administrator Infinity Complex Developer WPILA Lab Manager - AIM: CyberGrex ICQ: 3707881 Yahoo: CyberGrex_27 Cell: (410) 610-6343. - "Geek by nature, Linux by choice." -Original Message- From: Jones, Steven [mailto:sjones08@;eds.com] Sent: Monday, October 28, 2002 8:06 PM To: 'Stewart James'; [EMAIL PROTECTED] Subject: RE: DHCP ik campus ik ik so zilch physical security you didnt say this in your earlier post, this has severe security implications, in fact Id suggest you'd be a danger to the internet I'd suggest a letter to the ppl that want this and tell them of the severe secuity implications of what they want. you'd be a hackers/spammers dream...sit in the carpark with a laptop and wi-fi and spam the world. cant use static mapping of IPs to MACs.to many unknown MACs, well you can request each person registers thier machine with the helldesk and gets a static IP given out locked to the MAC address they provide. Run arpwatch to look for illegal connections We are trialing wi-fi city wide, the wi-fi lan is behind a firewall and are blocking port 25, then opening up ports as requested based on merits. DHCP is the least of your worries... This is not really a debian security issue but a general security issue, I would suggest you get a security policy written and get it agreed with "management". its your best set of defences from getting screwed over when something goes wrong. Also writing this and getting it agreed will give you time to research and get up to speed. Also the DHCP server should have a firewall of its own at the very least. It suggests careful planning is needed before implimentation, possibly a campus wide audit after a policy is agreed (you audit against the policy) regards Im writing a policy myself and its taking a while.it will be posted on the Internet once done for free use and comment. The debian security howto is good, if you have not read it please do. I'd split campus network up into a trusted and untrusted LAN )incl wi-fi network), the untrusted LAN should be treated as the Internet ie a danger zone and firewalled... i could go on and on..i suspect you have a lot to do.. regards Steven -Original Message- From: Stewart James [mailto:stewart.james@;vu.edu.au] Sent: Tuesday, 29 October 2002 12:53 To: [EMAIL PROTECTED] Subject: RE: DHCP I had the very same thoughts, being a university you can imagine what physical security is like, plus management wants to give students the ability to walk on campus and plugin, plus start wireless services too. >From what people have sent back from my question, I don;t think we will be any worse of security wise as far as moving to DHCP will go. Thanks for the various responses, if someone still thinks of a big issue I would love to hear it. Cheers, Stewart On Tue, 29 Oct 2002, Jones, Steven wrote: > Date: Tue, 29 Oct 2002 12:19:06 +1300 > From: "Jones, Steven" <[EMAIL PROTECTED]> > To: 'Stewart James' <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: RE: DHCP > Resent-Date: Mon, 28 Oct 2002 17:24:16 -0600 (CST) > Resent-From: [EMAIL PROTECTED] > > u could set dhcp to give out a fixed address dependant on a mac > address, this would stop just anybody plugging a box into a network, > if your network > is physically secure then thats not a worry. (a cat5 jack in reception > or some other public place is dodgy) > > Otherwise dhcp makes life easier...its the only way to manage a decent sized > network. > > :) > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
Re: Updated Package List
Good Day, Thanks for the response but my question was alike vague, what i meant to ask was about the security updates, if a package list containing the new ones was available anywhere for download (thats why I didnt post it to the regular user list, sorry, cant believe I didnt mention the security part :-) ) Thanks allot Ahmed Charles - Original Message - From: "Gareth Bowker" <[EMAIL PROTECTED]> To: "Ahmed Charles" <[EMAIL PROTECTED]> Cc: "debian-security users" Sent: Tuesday, July 30, 2002 6:58 PM Subject: Re: Updated Package List > On Tue, Jul 30, 2002 at 04:31:48PM -0400, Ahmed Charles wrote: > > Good Day, > > > > Is there an updated package list that i can download manually so that my > > dselect is up-to-date? > > > > And if there is, where can i get it? > > dselect has an "Update" option which will grab the latest packages list. It > does this by looking at /etc/apt/sources.list . This file tells dselect > (along with all the debian packaging tools, such as aptitude and apt) where > to get these files from. The file should look something like: > > deb ftp://ftp.uk.debian.org/debian/ unstable main contrib non-free > > take a look at the sources.list man pages for more info. Also, you might find > you'll get better and/or quicker responses sending messages to debian-user > rather than debian-security, as this isn't really a security-related question > (certainly not directly, anyway). > > Gareth >
Updated Package List
Good Day, Is there an updated package list that i can download manually so that my dselect is up-to-date? And if there is, where can i get it? Ahmed Charles
subscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh x forwarding
On Wed, Jul 10, 2002 at 11:41:34AM +0100, Alan James mumbled: > On Wed, 10 Jul 2002 01:29:52 -0700, xterminus <[EMAIL PROTECTED]> > wrote: > > >so things should run right? nope. when I try and fire up xeyes (to test), > >it just sits there for several minutes (literally) and does nothing. After > >waiting for a while, i get a > > > >"Error: Can't open display: localhost:10.0" > > > > This may be a daft question but.. > > "ping localhost" works right ? > ie there is a localhost entry in /etc/hosts ? > > Alan. This was exactly the problem. Thanks for pointing it out. My firewall had a typo, permitting anything on the l0 interface instead of the lo interface, so the default rule was catching that traffic and blocking anything directed at localhost. Fixed and all is working fine now. Thanks for your help. -- Take it easy, Charles Mauch <[EMAIL PROTECTED]> Please encrypt personal email with GnuPG, ascii format only -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Security Updates Sources
Hello Just a little question : is there a security updates sources for the woody release ? as : deb http://security.debian.org/ potato/updates main contrib non-free for the potato release ? Which i can put in my /etc/apt/sources.list ? Thanks Jean-Charles Preaux http://analogx.dyndns.org icq://125624822 ---Outgoing mail is certified Virus Free.Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.363 / Virus Database: 201 - Release Date: 21/05/2002
Security Updates Sources
Hello Just a little question : is there a security updates sources for the woody release ? as : deb http://security.debian.org/ potato/updates main contrib non-free for the potato release ? Which i can put in my /etc/apt/sources.list ? Thanks Jean-Charles Preaux http://analogx.dyndns.org icq://125624822 ---Outgoing mail is certified Virus Free.Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.363 / Virus Database: 201 - Release Date: 21/05/2002
Re: answer from abuse@ptd.net
bwuahahahahahaahhahahahahahhaahhahahahaahahhahahahahahaahahhahahahahahahahahaaa know how many copies of that i have on ptd account [EMAIL PROTECTED]
Re: answer from abuse@ptd.net
bwuahahahahahaahhahahahahahhaahhahahahaahahhahahahahahaahahhahahahahahahahahaaa know how many copies of that i have on ptd account [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secured bind default?
d to setup users and groups so that the service can run as a non-root user and still function correctly. Perhaps the most secure solution would be a combination of running the service as an unpriveleged user within a chroot. --8<-- snip -- Best Regards, Charles Stevenson Alvin Oga wrote: > > hi ya > > or one could write a new script to re-install it into its own chroot jail > > c ya > alvin > http://www.Linux-Sec.net/Harden/server.gwif.html#DNS .. DNS stuff > > On Thu, 12 Jul 2001, Sebastiaan wrote: > > > Hi, > > > > It is known that running a domain name server in a chroot jail is more > > secure than running it the default way. I have also heard this about other > > packages. So my question: would it not be smart/handy to have this > > opportunity during install? When installing bind, a question could be > > asked if you want it run default or in a chroot enviro. I do not think it > > is very difficult to extend the installation scripts? It would make > > security easier. > > > > Greetz, > > Sebastiaan > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secured bind default?
d to setup users and groups so that the service can run as a non-root user and still function correctly. Perhaps the most secure solution would be a combination of running the service as an unpriveleged user within a chroot. --8<-- snip -- Best Regards, Charles Stevenson Alvin Oga wrote: > > hi ya > > or one could write a new script to re-install it into its own chroot jail > > c ya > alvin > http://www.Linux-Sec.net/Harden/server.gwif.html#DNS .. DNS stuff > > On Thu, 12 Jul 2001, Sebastiaan wrote: > > > Hi, > > > > It is known that running a domain name server in a chroot jail is more > > secure than running it the default way. I have also heard this about other > > packages. So my question: would it not be smart/handy to have this > > opportunity during install? When installing bind, a question could be > > asked if you want it run default or in a chroot enviro. I do not think it > > is very difficult to extend the installation scripts? It would make > > security easier. > > > > Greetz, > > Sebastiaan > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secured bind default?
eed to setup users and groups so that the service can run as a non-root user and still function correctly. Perhaps the most secure solution would be a combination of running the service as an unpriveleged user within a chroot. --8<-- snip -- Best Regards, Charles Stevenson Alvin Oga wrote: > > hi ya > > or one could write a new script to re-install it into its own chroot jail > > c ya > alvin > http://www.Linux-Sec.net/Harden/server.gwif.html#DNS .. DNS stuff > > On Thu, 12 Jul 2001, Sebastiaan wrote: > > > Hi, > > > > It is known that running a domain name server in a chroot jail is more > > secure than running it the default way. I have also heard this about other > > packages. So my question: would it not be smart/handy to have this > > opportunity during install? When installing bind, a question could be > > asked if you want it run default or in a chroot enviro. I do not think it > > is very difficult to extend the installation scripts? It would make > > security easier. > > > > Greetz, > > Sebastiaan > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secured bind default?
eed to setup users and groups so that the service can run as a non-root user and still function correctly. Perhaps the most secure solution would be a combination of running the service as an unpriveleged user within a chroot. --8<-- snip -- Best Regards, Charles Stevenson Alvin Oga wrote: > > hi ya > > or one could write a new script to re-install it into its own chroot jail > > c ya > alvin > http://www.Linux-Sec.net/Harden/server.gwif.html#DNS .. DNS stuff > > On Thu, 12 Jul 2001, Sebastiaan wrote: > > > Hi, > > > > It is known that running a domain name server in a chroot jail is more > > secure than running it the default way. I have also heard this about other > > packages. So my question: would it not be smart/handy to have this > > opportunity during install? When installing bind, a question could be > > asked if you want it run default or in a chroot enviro. I do not think it > > is very difficult to extend the installation scripts? It would make > > security easier. > > > > Greetz, > > Sebastiaan > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with root on network clients
Alex Pires de Camargo a écrit : > Hi! > I administer a network with server and clients Debian based, > and would like to know if I can solve this problem. > It's a little easy to an user open a PC, damage the batteries, > boot with floppy and login as root in a client. But one thing is > undesirable. He can do su - and do many things on users > homes. The rootsquash options on nfs solve the problem when the > user is root, but as I explain, this is not sufficient. > Is there anything I'm forgetting to make? On server I run > potato, nis (not nis+), nfs-kernel-server. There's not much you can do when users have physical access to the boxes. You can use the Intrusion Sensors wich makes the box beep when the case gens opened, which makes the user feel particularly uncomfortable, or you can glue the case :) Some boxes have facilities to put a lock (a physical one) on them. One thing you can do with software is to encrypt filesystems, requiring a password to decrypt and therefore use the data on them. If your authentication requires some data that is on the crypted filesystem, users that boot from a floppy won't have access to it, and thus can not use your network. Put keep in mind that boxes with physical access are a PITA to secure and keep secured. HTH. -- Charles
Re: Problems with root on network clients
Alex Pires de Camargo a écrit : > Hi! > I administer a network with server and clients Debian based, > and would like to know if I can solve this problem. > It's a little easy to an user open a PC, damage the batteries, > boot with floppy and login as root in a client. But one thing is > undesirable. He can do su - and do many things on users > homes. The rootsquash options on nfs solve the problem when the > user is root, but as I explain, this is not sufficient. > Is there anything I'm forgetting to make? On server I run > potato, nis (not nis+), nfs-kernel-server. There's not much you can do when users have physical access to the boxes. You can use the Intrusion Sensors wich makes the box beep when the case gens opened, which makes the user feel particularly uncomfortable, or you can glue the case :) Some boxes have facilities to put a lock (a physical one) on them. One thing you can do with software is to encrypt filesystems, requiring a password to decrypt and therefore use the data on them. If your authentication requires some data that is on the crypted filesystem, users that boot from a floppy won't have access to it, and thus can not use your network. Put keep in mind that boxes with physical access are a PITA to secure and keep secured. HTH. -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
