Inquiry on Bullseye and https://security-tracker.debian.org/tracker/CVE-2019-8457
Hi Debian Security Team, I am inquiring on Debian Bullseye as it relates to: https://security-tracker.debian.org/tracker/CVE-2019-8457 Specifically, it is noted the team has put in a good faith effort in analyzing the feasibility of backporting relevant patches to Bullseye, and classifying the urgency of such effort. My read of this so far is that it's a debug mode only exposure, normally disabled in production (by default). With that said, for those environment who are using Bullseye, outside of the amount of changes required for the backport, is there any technical 'gotchas' or further advice the team could provide for those who are considering a self-maintain of relevant patches from bookworm / sid into Bullseye while the discussion continues on this? Thanks! - Chris Peñalver christopher.m.penal...@gmail.com
Re: rssh security update breaks rsync via Synology's "hyper backup"
Hi Russ,
> I've not done an LTS security upload before, but it looks from the wiki
> that it uses the same security-master process as stable security updates.
> Please let me know if that's wrong.
This is mostly correct, yep! I made the following the changes to
your jessie diff:
- * The fix for the scp security vulneraability in 2.3.4-5+deb9u1
+ * The fix for the scp security vulnerability in 2.3.4-4+deb8u2
.. and released this as a DLA-1660-2 "regression" update. I will leave
the stable update to the security team.
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Re: rssh security update breaks rsync via Synology's "hyper backup"
Antoine Beaupré wrote: > > Does this plan sound good to everyone? I'll follow up with the proposed > > diffs for stable and oldstable. > > Works for me (LTS), although I won't be the one performing the upgrade > (I've unclaimed the package for other reasons). Works for me too and happy to take this. Claimed package in: https://salsa.debian.org/security-tracker-team/security-tracker/commit/dd5c546e66da71f4029f09337a84aadaa527dcce Looking forward to receiving your debdiffs. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Re: rssh security update breaks rsync via Synology's "hyper backup"
[debian-security@lists.debian.org → Bcc] Holger Levsen wrote: > > I applied recent rssh security updates to Debian 8 (jessie) and I > > noticed that it breaks Synology's "Hyper backup" tool (with rsync method). > > > > Feb 10 03:28:21 roman rssh[19985]: cmd 'rsync' approved > > Feb 10 03:28:21 roman rssh[19985]: insecure rsync options in rsync > > command line! > > Feb 10 03:28:21 roman rssh[19985]: user synology attempted to execute > > forbidden commands > > Feb 10 03:28:21 roman rssh[19985]: command: rsync --server --daemon . > > > > Is it really unsafe to issue a "rsync --server --daemon ." command so it > > deserves to be blocked?` FYI this is the patch in question: https://sources.debian.org/src/rssh/2.3.4-11/debian/patches/0007-Verify-rsync-command-options.patch/#L15-L20 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
squid3 security update in oldstable
Hi LTS, security folks, I notice that squid3 was updated[1] in oldstable a few days ago (on the 23rd) but no DLA was issued and the security tracker[2] has not been updated: 1. https://tracker.debian.org/news/1005422/accepted-squid3-348-6deb8u6-source-all-amd64-into-oldstable/ 2. https://security-tracker.debian.org/tracker/CVE-2018-19132 Could I please have some clarification about this, as I'm reticent to install updates that haven't followed the full due process. Best regards, Chris -- Chris Boot bo...@debian.org GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE signature.asc Description: OpenPGP digital signature
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
Hi all, Just following up on this thread. As it's been a while, here's the thread index: https://lists.debian.org/debian-security/2017/01/threads.html#00014 ... but AIUI, the issue is as follows. Naturally, let me know if this a poor or inaccurate summary: * binNMUs do not bump debian/changelog. * This causes mtimes to to not be bumped in the (actually modified!) package. * Backup programs (eg. rsync) will therefore not believe a binary has changed and thus will be skipped over. * A binary restored from such a backup may not execute correctly. * Asking users to change anything at all is always problematic, but to ask them to switch to using (for example) --checksum with its non-trivial performance penalty is a very difficult ask indeed. Some backup programs may not even support such a mode anyway… My questions are as follows: a) Has anything changed in the meantime? b) Will this affect stretch? If so, what do we need to do now? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: [SECURITY] [DSA 3817-1] jbig2dec security update
On 24/03/17 22:32, Moritz Muehlenhoff wrote: > - > Debian Security Advisory DSA-3817-1 secur...@debian.org > https://www.debian.org/security/ Moritz Muehlenhoff > March 24, 2017https://www.debian.org/security/faq > - > > Package: jbig2dec > CVE ID : CVE-2016-9601 > > Multiple security issues have been found in the JBIG2 decoder library, > which may lead to lead to denial of service or the execution of arbitrary > code if a malformed image file (usually embedded in a PDF document) is > opened. > > For the stable distribution (jessie), this problem has been fixed in > version 0.13-4~deb8u1. Hi Security, Release folks, This security update is in the form of a new upstream release, going from 0.11+20120125-1 in stable to 0.13-4~deb8u1. I was rather alarmed to find the following entry in the NEWS.Debian file that appears to pertain to this update: > jbig2dec (0.12-1) unstable; urgency=medium > > * Licensing has changed to GNU Affero General Public License (AGPL). > Please ensure that all use complies with this new license. > > -- Jonas Smedegaard <d...@jones.dk> Fri, 31 Jul 2015 11:45:03 +0200 Was this expected? Has any thought been paid to people who use libjbig2dec in jessie currently that may fall foul of this license change? Thanks, Chris -- Chris Boot bo...@debian.org GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE
Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On 12/19/2016 06:26 PM, Patrick Schleizer wrote: What about Debian graphical installer security? Isn't that in meanwhile the ideal target for exploitation for targeted attacks? Because it will take a while until the Debian point release with fixed apt. And during the gui installer, the output of apt-get is not visible. And stuff during installer taking a long time is something users have been trained to expect. So I don't think it would raise much suspicion. If exploitation works, fine, if not, nothing was lost. Also Debian gui installer may be distinguishable over the network from already installed systems? Because first it's using debootstrap (perhaps with special options), then apt-get. The timing or something else could make it distinguishable over the network. Best regards, Patrick Probably so. But an attacker can be opportunistic--try and maybe fail/succeed--whether or not the user is installing or merely updating. The only solid solution to this issue is to alert users out-of-band, and have them also obtain *new media out-of-band* so they can re-install. In our case on Qubes, dom0 updates can fill the need for obtaining new media. But going forward, the best practice would include issuing new ISOs as well, since users installing Debian alongside Qubes will perform normal updates as a matter of course--they may review new CVEs or QSBs but not from several months prior. BTW, I think Debian's idea expecting users to validate detailed metadata with their eyeballs is crazy. Chris
Re: Call for testing: upcoming samba security update
On 14/04/16 10:02, Chris Boot wrote: > Firstly: > >> Finally, two important configuration options should be considered, >> that we were unable to silently change defaults for: >> - smb signing = required >> - ntlm auth = no >> >> Without smb signing = required, Man in the Middle attacks are >> still possible against our file server and classic/NT4-like/Samba3 >> Domain controller. (It is now enforced on our AD DC.) > > There is no parameter named "smb signing" in smb.conf, and Samba rightly > complains: > >> [2016/04/14 09:43:53, 0] ../lib/param/loadparm.c:743(lpcfg_map_parameter) >> Unknown parameter encountered: "smb signing" >> [2016/04/14 09:43:53, 0] >> ../lib/param/loadparm.c:1626(lpcfg_do_global_parameter) >> Ignoring unknown parameter "smb signing" > > I suspect you meant one/several of "client ipc signing", "client > signing" and/or "server signing" instead. Can you please clarify? Someone has pointed out to me by private mail that this has been fixed in an updated NEWS entry, and there is a bug open about it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820983 https://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?h=stable-update=cbcad2a543a28926ee712cf299dbdc03da351cb0 Please can we make sure that this makes it into the inevitable deb8u3 update? I'm filing a bug about the AD DC winbind issue now. Cheers, Chris -- Chris Boot Tiger Computing Ltd ISO27001:2013 Certified Tel: 01600 483 484 Web: https://www.tiger-computing.co.uk Registered in England. Company number: 3389961 Registered address: Wyastone Business Park, Wyastone Leys, Monmouth, NP25 3SR
Re: Call for testing: upcoming samba security update
On 12/04/16 21:27, Salvatore Bonaccorso wrote: > Hi > > The upcoming Samba update is bigger than usual since for Jessie an > update is needed to 4.2. We want to expose the package a bit more for > additional testing. Please test the packages found on [snip] Hi folks, So I missed the testing window and the updates are now out. There are a few problems, mostly with the NEWS.Debian file, which may lead to confusion and/or further issues. Firstly: > Finally, two important configuration options should be considered, > that we were unable to silently change defaults for: > - smb signing = required > - ntlm auth = no > > Without smb signing = required, Man in the Middle attacks are > still possible against our file server and classic/NT4-like/Samba3 > Domain controller. (It is now enforced on our AD DC.) There is no parameter named "smb signing" in smb.conf, and Samba rightly complains: > [2016/04/14 09:43:53, 0] ../lib/param/loadparm.c:743(lpcfg_map_parameter) > Unknown parameter encountered: "smb signing" > [2016/04/14 09:43:53, 0] > ../lib/param/loadparm.c:1626(lpcfg_do_global_parameter) > Ignoring unknown parameter "smb signing" I suspect you meant one/several of "client ipc signing", "client signing" and/or "server signing" instead. Can you please clarify? Secondly: When running a Samba 4 DC, the shift from 4.1 to 4.2 brings some major changes with it and people's smb.conf will need changing. The "server services" line needs "winbind" replacing with "winbindd", and the user must ensure the winbind package is installed. Otherwise, Samba will silently fail to provide a working DC. I will report these bugs on the samba package once I finish putting out some fires caused by all of this... HTH, Chris -- Chris Boot Tiger Computing Ltd ISO27001:2013 Certified Tel: 01600 483 484 Web: https://www.tiger-computing.co.uk Registered in England. Company number: 3389961 Registered address: Wyastone Business Park, Wyastone Leys, Monmouth, NP25 3SR
Re: Bug#810799: libcgi-session-perl: Perl DSA-3441-1 exposes taint bug in CGI::Session::Driver::file
Control: tag -1 security On 12/01/16 12:28, Chris Boot wrote: [snip] > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=80346 > > Dear Maintainer, > > With Perl upgraded from 5.20.2-3+deb8u1 to 5.20.2-3+deb8u2, our > installation of TWiki (http://twiki.org/) no longer functions. This > happens due to CGI::Session::Driver::file complaining about taint. I'm bringing this bug to the attention of the security team, as it has only come to light since the Jessie DSA of Perl (DSA-3441-1), so it's a stable security regression. Regards, Chris -- Chris Boot Tiger Computing Ltd IS27001:2013 Certified Tel: 01600 483 484 Web: https://www.tiger-computing.co.uk Registered in England. Company number: 3389961 Registered address: Wyastone Business Park, Wyastone Leys, Monmouth, NP25 3SR
Re: Bug#810799: libcgi-session-perl: Perl DSA-3441-1 exposes taint bug in CGI::Session::Driver::file
On 12/01/16 15:27, Salvatore Bonaccorso wrote: > My gut feeling about this: Since the issue was already present before, > uncovered indirectly by the perl DSA, and currently affects twiki (not > packaged in Debian), I would tend to ask the SRM to have the fix for > libcgi-session-perl to be scheduled via the next Jessie point release > rather than a DSA. > > Do you feel strong about having it the fix earlier via a DSA? I don't feel particularly strongly about it being fixed by a DSA as we have a workaround (though the patch I included previously is incorrect and broken; the patch in RT appears to work). That being said, ikiwiki (packaged) appears to use CGI::Session so I would be surprised if it was not affected, assuming it uses the same session storage driver. HTH, Chris -- Chris Boot Tiger Computing Ltd IS27001:2013 Certified Tel: 01600 483 484 Web: https://www.tiger-computing.co.uk Registered in England. Company number: 3389961 Registered address: Wyastone Business Park, Wyastone Leys, Monmouth, NP25 3SR
Re: [SECURITY] [DSA 3148-1] chromium-browser end of life
Hi, Can someone please point me to the upstream announcement for dropping gcc 4.7 support? I can't seem to find it, and I'd like to read up on the details why. Thanks, - Chris On Sat, Jan 31, 2015 at 05:13:26PM -0500, Michael Gilbert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-3148-1 secur...@debian.org http://www.debian.org/security/ Michael Gilbert January 31, 2015 http://www.debian.org/security/faq - - Package: chromium-browser Security support for the chromium web browser is now discontinued for the stable distribution (wheezy). Chromium upstream stopped supporting wheezy's build environment (gcc 4.7, make, etc.), so there is no longer any practical way to continue building security updates. Chromium users that desire continued security updates are encouraged to upgrade early to the upcoming stable release (jessie), Debian 8. An alternative is to switch to the iceweasel web browser, which will continue to recieve security updates in wheezy for some time. Note that until the official release happens, chromium package updates for jessie may have a larger than usual delay due to possible bugs and testing migration rules. Also, there will be no more DSAs announcing chromium package updates until jessie becomes officially released. Instructions for upgrading from Debian 7 to 8 are available at: https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html Media for installing Debian 8 from scratch are also available (the release candidate media, jessie_di_rc1, are recommended): http://www.debian.org/devel/debian-installer http://cdimage.debian.org/cdimage/jessie_di_rc1 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 iQQcBAEBCgAGBQJUzVNbAAoJELjWss0C1vRzeJ4f/jOV3x1a3ygWo5ZeLsh4yX2b IyEvuSzEQJMlwo8gZLNkCDg/6fdwbmatCy/AiSWSIoeQPHBGJ1CRUAoTsxvdPrRd FYryH5R6L6bO5ADmQxirQb/mTHvvw228EBRhbCjVbjUe+dstRhkwIDz0I39cRd13 7UY0KS+GusmviocafghxjTjtsFOVv6HsqzYRCYB2DYTvumiJa/egJHuGqtFTU216 jUlPzMMvWopI6Gm4rc+L2Q2RZrK03AVr8xygRlYDUoNhOHUxVACtjrrjQJ3UJb5N 1HJ+A7j6MdHKOvTuHpMDYtxS9d+uwkiAb23VSeb4LxnH3idsQEsMrzXQf6KU1A5p KBkjwg1G6ZQ2EXG/PLjuYj0O/n7Xyrs0RwyRSWSU3rRqa3pTy4MTvDgFTYcTY7Vj 6T1kZZZBfBFtOAReFFtDcu9/5LL4qmtC0eGn0Fh3X86V4/gKcOnJ2iRNok0u5d7k nF4HNcHGIdgQ0tjAW0DMNWfLq9AucAH6rZswnF1XpM5TOZze3M61lE6Y46bT1IHx LXYeQxf0wY0Dw5StT1zMbyCMNpsFrvts6fcs3STdAdF3+smJ4uys08L+AiTbzTbO izo07eJylVQJzm31YXdV/M4LAsHZpPtXLntEsfAB5jwMqH+lGhKjy9OwhFhvhDKE 8FZ4YRXii/RN6ofjcyuzYRfVZx+6rQcgreAFNKGp9XCY3qWdUIIXcGMp9DP7npoA YXwnJo4AgweGgwUBvk6Ak8J7Pd5ubpMF4DwLT35yE/GgPOMn0Y+159Uzh7gA0LXR PLL6GbcbfmamkOK3c7/5ulEUUmZ8XNFxBBKPfEN93K3wnep61qjEPeDtiOdeAsiM yoz6oGYF9PLG5A7N0BK9suTtwESUB7DH7JHW61rZw2sFnnpYvo7dQGvoEUYezICv 5o/kI+/4EXASCi1hBQBC3auSGPz/Sat9j+mMPHIDo/9g/LrOhB3X2q0C4YaG6Aja HVKCOW377RYwa8aCmw4XouXeAnlliUzUKUVBrss74Pze0BHbkHQAwhNUYhVsOojb 4JV5sE/7ooOCduxWuhCG77tKIBxzjGebzz9AllzdcJ6JBcix9v8p1HoVRp8vaDrP o/hEzjxuU0Y5h+fjoJ9w60t1NkVrYRQA0qoFGK7uvQZfvKLi84aKu9KBmxaXyzvX 3SCTVAjJ5pOA7Fy1FszLG908rBzrUOBouX2zImw05JnaqZXyxqcCVxGcYlNg5LUf 4qWPA/BVSY2ZEvP1ZSq5bqvKGi/k8HmBiJ9/ZwJGecGZzn+jVaYrYfZW+n0ZvIdR +W1u3meH1H+lEqrTmAhK4c/qJAVFXSBSdOuVISYnX5CNixm3uPHOiev0KsSGJtw= =s8I8 -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/e1yhgia-0002ro...@alpha.psidef.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/20150201051501.ga30...@foursquare.net
Patch / update for znc to disable weak ciphers and SSLv2/SSLv3 protocols
Hi, the ZNC IRC Bouncer (https://packages.debian.org/wheezy/znc) finally allows to choose own ciphers and to disable SSLv2/SSLv3 protocols with this pull requests: https://github.com/znc/znc/pull/716 https://github.com/znc/znc/pull/717 Not sure if those are easy to apply to the older version 0.206-2 in Wheezy but want to report this anyway. -- 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/trinity-29ef7d37-1c9a-47bd-9e19-29fdca43f13b-1414392521343@3capp-gmx-bs64
Re: Patch / update for znc to disable weak ciphers and SSLv2/SSLv3 protocols
Hi, Would you be so kind to file this as a bug against the znc package? and thanks for the hint. Just created a new bugreport against the znc package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766957 -- 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/d6775728-6802-4c27-83df-b1399a972...@gmx.de
Re: Debian mirrors and MITM
On 30/05/14 13:43, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? Oh god not this again. How exactly does using HTTPS solve this particular problem, anyway? If we assume a compromised APT then surely it can pass invalid SSL certificates as perfectly valid, too. It's not like sponsored attackers don't have access to all the SSL certificates they might ever want anyway. -- Chris Boot bo...@bootc.net -- 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/53887e4b.90...@bootc.net
Re: Debian mirrors and MITM
On 30/05/2014 8:52 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: What's stopping the attacker from serving a compromised apt? https://www.debian.org/CD/verify That will cover the installer, for the packages see: https://wiki.debian.org/SecureApt -- 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/53887f7a.2050...@shthead.com
Re: [SECURITY] [DSA 2819-1] End-of-life announcement for iceape
Where can I find more information on this? Is this for old-stable? Or for the latest 7.3 Debian? Was support dropped due to lack of manpower? And what were the main differences between upstream Seamonkey and the Debian-branded version? If Seamonkey is still supported, why not just package that one? Thanks, - Chris On Mon, Dec 16, 2013 at 05:03:01PM +0100, Moritz Muehlenhoff wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2819-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff December 16, 2013 http://www.debian.org/security/faq - - Package: iceape Security support for Iceape, the Debian-branded version of the Seamonkey suite needed to be stopped before the end of the regular security maintenance life cycle. We recommend to migrate to Iceweasel for the web browser functionality and to Icedove for the e-mail bits. Iceweasel and Icedove are based on the same codebase and will continue to be supported with security updates. Alternatively you can switch to the binaries provided by Mozilla available at http://www.seamonkey-project.org/releases/ Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlKvJBMACgkQXm3vHE4uyloALgCfU5PPVJ7Ajg4g1MestH4cEcxl +0cAn3cqG8HvyUNp4ACD9/96gZG5HigR =AbYs -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: http://lists.debian.org/20131216160301.GA4732@pisco.westfalen.local -- 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/20131216164400.ga31...@foursquare.net
Re: Daemon umask
Mike Mestnik cheako+debian-secur...@mikemestnik.net wrote: Actually I'm unsure if a shell would be invoked in most cases. For example Apache starts as root and drops privs after opening up log files(I wish someone would fix this) and port 80(I wish this could be done with an ACL). Sorry, it's not clear to me what it is that you want fixed. Can you elaborate? Chris -- 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/rj1df9xmr7@news.roaima.co.uk
Re: php5: many of the open unimportant issues would seem to be fixed?
On Tue, Apr 24, 2012 at 05:06:26AM +0200, Nico Golde wrote: * Chris Butler chr...@debian.org [2012-04-23 14:51]: From a quick scan, it seems that CVE-2010-3064 is a likely cut-off point, as it seems to be the last one listed as affecting PHP 5.3 through 5.3.2. Although I'm a little bit busy right at the moment, I can probably have a more detailed look through the list later today when I have a bit more spare time, if that would help. What is this exactly based on? Cause the CVE id description is unfortunately not very reliable. Ah, I wasn't aware of that, thanks for the heads-up. It was mostly based on looking at the description, although a couple of the ones I picked at random were also listed as fixed in the PHP changelog pre-5.3.3.. It was just a quick scan of the list at the time, as I didn't have time to go into detail. I started having a closer look through the list last night, and will let the list know once I've got some more useful/accurate data... -- Chris Butler chr...@debian.org GnuPG Key ID: 4096R/49E3ACD3 -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120424100717.gn20...@crustynet.org.uk
Re: [SECURITY] [DSA 2422-1] file security update
On Sat, Mar 03, 2012 at 09:34:18AM +0100, Thijs Kinkhorst wrote: On Sat, March 3, 2012 02:52, Chris Frey wrote: I've done the latest update, but apt-cache show file still shows version 5.04-5 available, instead of 5.04-5+squeeze1. You are probably using one of the following archs: armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips Unfortunately these builds are not uploaded yet. I'll ask the appropriate team to help in getting this resolved. Yes, I'm using i386. Thanks very much for looking into this. - Chris -- 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/20120303083618.ga20...@foursquare.net
Re: [SECURITY] [DSA 2422-1] file security update
Hi, I've done the latest update, but apt-cache show file still shows version 5.04-5 available, instead of 5.04-5+squeeze1. My sources.list contains: deb http://ftp.us.debian.org/debian/ squeeze main contrib non-free deb-src http://ftp.us.debian.org/debian/ squeeze main contrib non-free deb http://ftp.us.debian.org/debian/ squeeze-updates main contrib non-free deb-src http://ftp.us.debian.org/debian/ squeeze-updates main contrib non-free deb http://security.debian.org/ squeeze/updates main contrib non-free deb-src http://security.debian.org/ squeeze/updates main contrib non-free Thanks, - Chris On Wed, Feb 29, 2012 at 09:54:44PM +0100, Florian Weimer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2422-1 secur...@debian.org http://www.debian.org/security/Florian Weimer February 29, 2012 http://www.debian.org/security/faq - - Package: file Vulnerability : missing bounds checks Problem type : remote Debian-specific: no The file type identification tool, file, and its associated library, libmagic, do not properly process malformed files in the Composite Document File (CDF) format, leading to crashes. Note that after this update, file may return different detection results for CDF files (well-formed or not). The new detections are believed to be more accurate. For the stable distribution (squeeze), this problem has been fixed in version 5.04-5+squeeze1. We recommend that you upgrade your file packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJPTpUrAAoJEL97/wQC1SS+xjIH/RKCNTX9XDy9RmKnLubx5gME e3MOWFZHk0ZOaNAuorRmyrxygbRkLPVMNECTKenv2eE1CORYIHBvzFDZXNn0Yl+9 +NS2KkmwpigU33Tu/8NfuG/xsoLl9fS1a3iJU+yVeEC14gdr0Nw5OtLzSP5C6HUS KcXZRXQZoHs21SrdotBm0Lx86tmoluZ1QtWmlacJcFnGwMLi3sRBwkE57UufEgCj dd8BD79tdVWm2YlPjnnfpG8Pe+ikq4tIxDHEKHfsFudUxgeSDAZaHjBvF/2xXrxn nEjOjbCpaQT9hUaaBzAxFh10qPiKKV4oA3ueR1RZt/T8XMbTXJAM54NYutF2b7Q= =kRH8 -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: http://lists.debian.org/87aa41e4x7@mid.deneb.enyo.de -- 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/20120303015214.ga1...@foursquare.net
Re: how to fix rootkit?
On Wed, 2012-02-08 at 22:56, Chris Davies wrote: You can no longer trust the kernel [...] Milan P. Stanic m...@arvanta.net wrote: Of course, you are right here. But then I don't trust the CPU's. How we know that the manufacturer od CPU, Ethernet card or anything, didn't put some secret code into device [...] You don't. But since your scenario applies whether or not someone's system has been rooted, it should probably remain outside the scope of the discussion. Chris -- 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/2p4d09xej3@news.roaima.co.uk
Re: how to fix rootkit?
Milan P. Stanic m...@arvanta.net wrote: What about statically linked binaries on the external media (CD, DVD, USB ...) which is write protected with 'execute in place' mode? You can no longer trust the kernel. Therefore you cannot trust ANY application that runs under that kernel, either directly or indirectly. Period. Chris -- 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/g5bb09xbl5@news.roaima.co.uk
Re: Default valid shells and home dir permissions
Davit Avsharyan avshar...@gmail.com wrote:
1/ I'm wondering why most of the system users have valid shells by
default ?
/cat /etc/passwd | grep -E '(sh|bash)' | wc -l
*21*/
That's not necessarily sufficient to determine valid shells: the absence
of a shell definition implies the use of /bin/sh, so you need to check
that, too.
Something like this should probably give you a definitive list -
SS=$(grep '^/' /etc/shells | xargs)
for S in $SS ''; do
getent passwd | awk -F: -v S=$S '{if ($7 == S) print $1, $7}'
done
Chris
--
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/djs2u8xfrv@news.roaima.co.uk
Re: Default valid shells and home dir permissions
Poison Bit poison...@gmail.com wrote: Why filter to those in /etc/shells ? I mean... the filter should be applied by the system :) Mainly because it's a convenient list of real shells, and some of the remote service applications require a shell to be in that list. FTP is one such that springs to mind. As a counter example, /bin/false is a possible shell but it doesn't provide a particularly useful environment for the user. You could change the scriptlet to check for the 7th column being either empty or an executable file if you preferred. But neither of both codes take in mind if there is sudo in the system, and what is gained in its config. I don't recall the OP mentioning access via sudo. (BICBW.) Also, neither of both codes think about ForceCommand in ssh... So I maybe listed as /bin/bash, but I me be able only of run /usr/bin/cal once as my shell and get kicked. ForceCommand requires an interactive shell-like login on the target, so I don't believe that's relevant here. Chris -- 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/uad3u8x037@news.roaima.co.uk
Re: [SECURITY] [DSA 2341-1] iceweasel security update
Hi, I think one of the security.debian.org mirrors is lagging fairly badly. I just did an update, and this update from yesterday was not available. I did it again (presumably getting a different IP) and it was available. Just a FYI. Thanks, - Chris On Wed, Nov 09, 2011 at 05:45:01PM +0100, Moritz Muehlenhoff wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2341-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff November 09, 2011 http://www.debian.org/security/faq - - Package: iceweasel Vulnerability : several Problem type : remote Debian-specific: no CVE ID : CVE-2011-3647 CVE-2011-3648 CVE-2011-3650 Several vulnerabilities have been discovered in Iceweasel, a web browser based on Firefox. The included XULRunner library provides rendering services for several other applications included in Debian. CVE-2011-3647 moz_bug_r_a4 discovered a privilege escalation vulnerability in addon handling. CVE-2011-3648 Yosuke Hasegawa discovered that incorrect handling of Shift-JIS encodings could lead to cross-site scripting. CVE-2011-3650 Marc Schoenefeld discovered that profiling the Javascript code could lead to memory corruption. For the oldstable distribution (lenny), this problem has been fixed in version 1.9.0.19-15 of the xulrunner source package. For the stable distribution (squeeze), this problem has been fixed in version 3.5.16-11. For the unstable distribution (sid), this problem has been fixed in version 8.0-1. We recommend that you upgrade your iceweasel packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk66rcYACgkQXm3vHE4uylqo9QCgsdGqCrDS99Eqo1QHA3G/LyMP /aQAoMGeYFbcebA+ulmKJi94hEYrnLql =H/MJ -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: http://lists.debian.org/2009164501.GA4188@pisco.westfalen.local -- 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/2010221149.ga16...@foursquare.net
Re: [SECURITY] [DSA 2315-1] openoffice.org security update
I assume this would include LibreOffice? – Chris On Wed, Oct 5, 2011 at 9:14 AM, Giuseppe Iuculano iucul...@debian.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2315-1 secur...@debian.org http://www.debian.org/security/ Giuseppe Iuculano October 05, 2011 http://www.debian.org/security/faq - - Package: openoffice.org Vulnerability : multiple vulnerabilities Problem type : remote Debian-specific: no CVE ID : CVE-2011-2713 Red Hat, Inc. security researcher Huzaifa Sidhpurwala reported multiple vulnerabilities in the binary Microsoft Word (doc) file format importer of OpenOffice.org, a full-featured office productivity suite that provides a near drop-in replacement for Microsoft(R) Office. For the oldstable distribution (lenny), this problem has been fixed in version 1:2.4.1+dfsg-1+lenny12. For the stable distribution (squeeze), this problem has been fixed in version 1:3.2.1-11+squeeze4. For the testing distribution (wheezy), and the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your openoffice.org packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6MZloACgkQNxpp46476aquFACePG1/V0rwdm5fHcCD/1Z6JwdM 9HkAnicN4tRFTNJlamHHe7TnBnFZmQS0 =vJkV -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: http://lists.debian.org/20111005141450.ga25...@sd6-casa.iuculano.it
Re: Lenny version info
Well, you have my apologies, for whatever that's worth. I hate seeing exchanges like this. In the time it takes to tell somebody to Google it, one could have simply replied with the correct answer. It's also worth noting that while search engines sometimes seem magical, they're simply indexing lots of possible answers -- some correct, some not. This mailing list and others do get archived and indexed eventually, so adding correct answers to the mix will only improve Google's signal to noise ratio in the long run. If anybody'd like to flame me for this email, that's fine. All I ask is that you do so to my personal email address and not to the list. Best regards, -Chris On 12/13/2010 05:12 PM, Ash Narayanan wrote: Wow, what has this thread turned into!? It started off as a simple question that could have been answered with one of two possible replies, namely, the solution itself or a suggestion to move this query to a more appropriate mailing list. Thank you to all of you whose replies fell in either of these two categories. To the rest of youwhat is wrong with you? If you don't want to help, don't. Stop wasting time. Did it ever ocur to you that not everyone out there likes using a search engine? I was directed to debian-security by an ex-colleague since one of our servers uses debian. So I used it to ask a question that wasn't exactly related to security (although if you must know, it stemmed from another discussion on debian-security that did relate to security and one of my concerns was the version number of my system). So what? The responses I've received from you make me feel like I've committed a crime against humanity! Can you imagine stepping in to a pet store with a question about your pets symptoms to be abused by the store attendant for not going to a vet instead? Ash PS: I've solved my problem. Thanks to those that actually helped. -- 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/4d06ce46.9050...@gmail.com
Re: Linux infected ?
Ralph Jenkin ralph.jen...@empoweredcomms.com.au wrote: Am I the only one thinking; Wine can actually manage to get infected by malware now? Cool. I've seen a fair number of discussions about this on usenet, so it's not new, no. Chris -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1712-1] New rt2400 packages fix arbitrary code execution
Moritz Muehlenhoff wrote: - Debian Security Advisory DSA-1712-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff January 28, 2009 http://www.debian.org/security/faq - Package: rt2400 Vulnerability : integer overflow Problem type : remote Debian-specific: no CVE Id(s) : CVE-2009-0282 It was discovered that an integer overflow in the Probe Request packet parser of the Ralinktech wireless drivers might lead to remote denial of service or the execution of arbitrary code. Not for us. Regards, -- Chris Lamb, www.playfire.com/lambyGPG: 0x634F9A20 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1713-1] New rt2500 packages fix arbitrary code execution
Moritz Muehlenhoff wrote: - Debian Security Advisory DSA-1713-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff January 28, 2009 http://www.debian.org/security/faq - Package: rt2500 Vulnerability : integer overflow Problem type : remote Debian-specific: no CVE Id(s) : CVE-2009-0282 It was discovered that an integer overflow in the Probe Request packet parser of the Ralinktech wireless drivers might lead to remote denial of service or the execution of arbitrary code. Not for us. Regards, -- Chris Lamb, www.playfire.com/lambyGPG: 0x634F9A20 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Rainbow tables on Linux?
Johan 'yosh' Marklund [EMAIL PROTECTED] wrote: the open source rainbow tables are about 121GB (if my memory serves me correctly) and are only available via bittorrent. I think it took me about 2 months to download them. http://www.antsight.com/zsl/rainbowcrack/ Out of interest, how long do you estimate it would have taken you to generate them locally? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh-vulnkey and authorized_keys
On May 15, 2008, at 6:25 PM, Alex Samad wrote:
is there away to check x509 certs with these tools ?
Yes - the wiki has one (http://wiki.debian.org/SSLkeys) but you might
prefer the openssl-blacklist package which Ubuntu prepared:
https://launchpad.net/ubuntu/+source/openssl-blacklist/
It runs out of the box on Debian and if you edit debian/control to
change the openssl dependency from the Ubuntu version
(0.9.8g-4ubuntu3.1) to the Debian version (0.9.8c-4etch3) you can dpkg-
buildpackage it and deploy it to multiple systems. I used it like this
to flush out Apache keys:
sudo find /etc/ -xdev -type f -name \*.key -exec openssl-vulnkey {} \;
Chris
smime.p7s
Description: S/MIME cryptographic signature
Re: Why not have firewall rules by default?
Am 2008-01-23 09:19:01, schrieb William Twomey: It's my understanding (and experience) that a Debian system by default is vulnerable to SYN flooding (at least when running services) and other such mischeif. I was curious as to why tcp_syncookies (and similar things) are not enabled by default. Hmm, in three month I am using Debian GNU/linux since 9 years and was never synflooded or hacked and currenly I am maintaining a world wide network of 280 Servers and over 900 Workstations... Ind I have services running, but at least only those, which are REALY required and not more. Many distros (RPM-based mostly from my experience) ask you during the install if you'd like to enable firewall protection. I was curious if debian was every going to have this as an option? Sorry, but Debian is NOT a install and do not ask questions distri. Here, the $USER has the choice of a couple of different firewall solutions and some $USER may use only an $EDITOR and hack some ipt lines down. One solution could be to have a folder called /etc/security/iptables that contains files that get passed to iptables at startup (in the same way /etc/rc2.d gets read in numeric order). So you could have files like 22ssh, 23ftp, etc. with iptable rules in each file. You could also have an 'ENABLED' variable like some files in /etc/default have (so that ports wouldn't be opened by default; the user would have to manually enable them for the port to be opened). Then they'd just run /etc/init.d/iptables restart and the port would be opened (flush the rules, reapply). Nice idea, but not flexible enough since it CAN conflict with most firewall solutions. Even a central iptables-save format file that gets passed to iptables at startup would be nice. It's easy enough to do manually, but would be nice to see integrated with debian itself (packages managing their own rules, etc.). But for most firewall solutions not usable... I have already tried the ipt-save/restor stuff on my routers but it let me drive crazy... Is debian every going to introduce a better way of having iptables rules be run at startup and easily saved/managed, or will this always be a manual process? I think not. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- What about Firestarter? (www.fs-security.com). Is it a good solution to a personal use firewall? -Ferg @ www.FergSoft.com USMC Linux User #463470 at counter.li.org
Re: spooky windows script
On May 8, 2007, at 9:17 AM, Jan Outhuis wrote: The script gets typed in any window that's active at the moment the cursor is being taken over: it may be the Firefox 'find'-field or a terminal window for that matter. Do you have a VNC server installed? If so you really want to either remove it or configure it to only listen on localhost so you can access it over an SSH tunnel but remote attackers can't get in. I'd also strongly recommend that you configure the built-in firewall since it you may have other exposed services - unfortunately I don't have a package recommendation as I just configure iptables directly. I've seen this happen a couple of times on Macs where people inadvertently left VNC open w/o a password with very similar behaviour, which suggests people are scanning for vulnerable VNC installs but the automated stuff currently only has Windows exploits. Chris smime.p7s Description: S/MIME cryptographic signature
Re: Problems after sendmail security upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel Halbwachs wrote: We are experiencing problems after the sendmail security upgrade on our mailhost. What sort of problems, exactly? - is there a way to downgrade the sendmail packages to the previous version before the security fix ? (i. e. something with apt-pinning) If you can find a .deb of the package version you want, something like: dpkg --force-downgrade --install sendmail-whatever.deb should do the trick. Be aware that forcing a downgrade doesn't check for dependencies on the newer, replaced version of the package. - -- Chris Hilts [EMAIL PROTECTED] Say it with flowers -- Send them a triffid! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFEJC6g98ixrK2vMtARAoQzAKCJppzEOmLupmqX5UPhlU+b93EXAwCgk25D dZWT1UyV8F/OVYomGj51m7M= =JayI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using multicast for security updates
On Feb 23, 2006, at 4:22 PM, Edward Faulkner wrote: On Fri, Feb 24, 2006 at 11:13:35AM +1100, Geoff Crompton wrote: When you say The server runs a tracker, are you explaining bittorrent, or do the security.debian.org servers actually run a tracker at the moment? I was just explaining bittorrent. Sorry for the confusion. How well does bittorrent work for smaller files? I was always under the (possibly mistaken) impression that it worked really well for iso sized images (and larger) because the size allowed plenty of time for the chunks to get distributed well through out the network. You're probably right. If the files are too small, the overhead dominates. FYI, there is an apt-torrent program, googled and located at http:// sianka.free.fr/ Since we are talking of writing new software anyways, either for bittorrent or multicast, instead of a torrent for each individual package, there could be a torrent file for the entire current archive. Perhaps in addition to the Packages and Release files, a torrent file could be that mentions the entire archive. The question becomes, is this system used to install software, or mirror it. Mirrors would enjoy this, but would mean changing the debian mirroring infrastructure. For installations, in becomes more difficult I believe. The way I see apt-get work, is it queries a server for a copy of a file, waits for it to arrive, and then get the next. This would be bad download performance in a bittorrent environment. If apt could request the local daemon for all the files it wants, and get them in any order. *Idea* If the bittorrent source of the apt was the first to be queried, if it did not have the package yet, it would 404, allowing apt to go onto the next source. BUT, it would then note the name of the package requested, and start to always try and have the most recent copy of that package around. Therefore if the following week, and update was released, the bittorrent source would notice a new version of the package available, and download it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
On 2005-07-29, at 9:43 AM, Martin Schulze wrote: Using new upstream versions are bound to cause new problems. Maybe not at the moment with only going from 1.0.4 to 1.0.6 but more probably they will do later. ... I guess in the long term we're on a lost track and it seems this situation has already started. I'm inclined to say that it'd be better to ship the current release (or the earliest Mozilla-supported version for major releases) until these problems actually do become more work than the backports. The rationale is basically that the usual concerns apply less to browsers since they're less mission critical, people are more used to frequent updates (and tend to have fewer dependencies on specific versions), and new features are more useful because websites which use them are widely deployed independently of whatever Debian or the sysadmin do. Given the threat exposure I think it makes more sense to stick with what the rest of the world is using (especially in cases where the fixes are not well localized), particularly since there are areas where the new features in point upgrades can add almost as much value as the pure security updates - when things like spam filters or anti- spoofing technology improve it's frequently in response to changes in the attackers' behavior, which a pure back-port model can't account for, and that generally means that even if the old software works perfectly the users are going to be complaining because they're seeing more successful attacks. We saw this in the past with SpamAssassin; it pushed us to rush newer versions into production because the tradeoff was between the certainty of My spam filter isn't working! complaints versus a relatively low-probability chance of finding a backwards-compatibility bug - not a decision I'm entirely happy about but it's definitely proven to be the better course so far. Chris smime.p7s Description: S/MIME cryptographic signature
Re: Darn skiddies (ssh login attempts)
Michael Stone wrote: Depending on the attack. That's the point I'm making--rsa keys protect against certain attacks but do absolutely nothing about other attacks and shouldn't be seen as a magic bullet. They were also never portrayed as such - merely an additional layer of protection which has the side benefit of completely blocking some very widespread attacks. Central distribution is also quite easy and allows you to decide how much control you want over the process - simply change the authorized key path to a directory which isn't user-writable and use your existing management tools to synchronize changed keys. Dude, that does *nothing* to manage the private key. It allows you to step in the middle of the process - it's not simply a question of dropping a file in ~/.ssh/ with no checks. Since the user can't use any key they want this allows you have, say, a process of requiring a decent password, stashing the public key somewhere else, making the private key file immutable to prevent password changes or removal, and record an audit log entry (all of which could be done by an ssh-keygen wrapper). Only if the key wasn't protected with a password - sure, it's possible for an attacker to brute-force the key but that's a lot more work than they'd have to do if you're using password authentication and it gives you more time to detect the intrusion and get users to change their keys. Huh? You do realize that the passphrase on the private key can be brute forced, and that it's possible to do so without connecting to the target system at all? All of which is irrelevent - we're comparing it to plaintext authentication, where our hypothetical attacker already has their password without having to brute force anything. It also requires you to have a copy of the keyfile in the first place, which is harder than firing up an ssh brute-force bot. More importantly, good policy also tells users to use ssh-agent instead of copying private keys all over the place - sure, not everyone will do it but the same is true of password policies No, password policies are enforceable--you control what the user can set the password to. Key management policies are not enforceable. Right, but in the real world password policies don't work so well because normal humans don't handle high-entropy passwords well and they're going to find an algorithm which your policy doesn't catch, generate helpdesk traffic due to lost passwords and store it insecurely because they don't always remember it. The details aren't equivalent but the underlying problem is: you're going to have to depend on your users cooperating with your policy; if it's too onerous they'll find some way around it. ssh-agent also intruduces another vulnerability in that new sessions can be started using the secret key for authentication without the user being aware that it's happening. That's not actually true for all ssh-agent implementations but in any case, it's simply restating a point which was never in question: if the attacker has compromised the user's client they can already do anything they want. If they can violate host security to abuse your ssh-agent they can also capture everything else you do. The easiest way is simply to replace ssh-keygen with a wrapper which calls cracklib before passing the password to the real ssh-keygen. This also has the advantage of reusing any existing cracklib policy. Interesting. Now how do you keep the user from resetting their password on any system where you aren't controlling the ssh-keygen? The system I outlined above means that they can't simply use any random ssh key but, frankly, if your users are actively trying to subvert your security system you have bigger problems than script kiddies. You also can't prevent them from writing their password down, giving it to their office-mates, hard-coding it in a configuration file or storing it in some app's weak password store. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Mar 31, 2005, at 11:40 PM, Robert Lemmen wrote: On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... of course the only thing that really helps is good passwords, Or no passwords - if requiring public key authentication is feasible for a system you can disable password authentication entirely: PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no PAMAuthenticationViaKbdInt no If you have systems which for various reasons need to be accessible from many locations this is an excellent way to sleep a little easier. Given that many utilities exist to simplify ssh-agent use it's starting to be feasible to switch user-visible machines over to this configuration in many environments - ease of use is a big carrot. Chris smime.p7s Description: S/MIME cryptographic signature
Apache-SSL and DSA-532
DSA-532 contained: Package: libapache-mod-ssl Vulnerability : several Problem-Type : remote Debian-specific: no CVE Ids: CAN-2004-0488 CAN-2004-0700 Is apache-ssl also vulnerable to these? Thanks -- Chris No candidate achieved quota: | Candidates elected: Action: Eliminate 150 students and| Yes transfer their votes. - DEVote (11/3/04) | - Beremiz (13/3/04) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
subscribe
-- Chris James http://www.chrisjames.me.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Chris Luton/CBR/IPAustralia is out of the office.
I will be out of the office starting 09/06/2004 and will not return until 27/06/2004. I will respond to your message when I return.
Re: name based virtual host and apache-ssl - thanx
At 18:14 on Wed, 24 Mar 2004, Elmar S. Heeb wrote: Well, actually there is a solution: use wild cards in the name of the keys. You can make the certificate for *.mycompany.com for several web sites within mycompany.com, or you can go so far as to use * for any host name. Most modern browsers will accept such a certificate, some will complain and still accept it. In my experience, *.mycompany.com would match foo.mycompany.com but not foo.bar.mycompany.com - which may be sufficient if you can get into people's heads that the domains are www.mycompany.com and sales.mycompany.com and definitely not www.sales.mycompany.com So I have a feeling that * would match 'com' or 'org' but nothing more useful. Though it may vary from browser to browser. -- Chris No candidate achieved quota: | Candidates elected: Action: Eliminate 150 students and| Yes transfer their votes. - DEVote (11/3/04) | - Beremiz (13/3/04) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: name based virtual host and apache-ssl - thanx
At 18:14 on Wed, 24 Mar 2004, Elmar S. Heeb wrote: Well, actually there is a solution: use wild cards in the name of the keys. You can make the certificate for *.mycompany.com for several web sites within mycompany.com, or you can go so far as to use * for any host name. Most modern browsers will accept such a certificate, some will complain and still accept it. In my experience, *.mycompany.com would match foo.mycompany.com but not foo.bar.mycompany.com - which may be sufficient if you can get into people's heads that the domains are www.mycompany.com and sales.mycompany.com and definitely not www.sales.mycompany.com So I have a feeling that * would match 'com' or 'org' but nothing more useful. Though it may vary from browser to browser. -- Chris No candidate achieved quota: | Candidates elected: Action: Eliminate 150 students and| Yes transfer their votes. - DEVote (11/3/04) | - Beremiz (13/3/04)
Re: (php?) bug exploit report
At 10:00 on Tue, 20 Jan 2004, Oliver Hitz wrote: On 19 Jan 2004, Csan wrote: The URL is part of a postnuke site and they could start up the telnetd binary with invoking an URL similar to the above URL! Is this a known sechole? I think you should be able to avoid such exploits by using PHP's safe mode. It allow you, among other things, to specify that only files in a particular directory may be executed. This way, even if someone succeeds uploading an exploit onto your server, he won't be able to run it. Safe mode would certainly have reduced the impact from that script, and I'd definitely recommend turning it on unless you're very confident of the quality of all your scripts. However, some of the things in the exploit script were designed to let an attacker look at safe mode systems and possibly find another vulnerability. Certainly they'd have been able to get at any database/etc passwords used by the exploited website, possibly, depending on file system permissions, at most files belonging to the same user, even with safe mode on. This might then have let them find another way of attacking. -- Chris Those who do not remember the past are condemned to repeat it. Those who *do* remember the past don't get much choice either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (php?) bug exploit report
At 10:00 on Tue, 20 Jan 2004, Oliver Hitz wrote: On 19 Jan 2004, Csan wrote: The URL is part of a postnuke site and they could start up the telnetd binary with invoking an URL similar to the above URL! Is this a known sechole? I think you should be able to avoid such exploits by using PHP's safe mode. It allow you, among other things, to specify that only files in a particular directory may be executed. This way, even if someone succeeds uploading an exploit onto your server, he won't be able to run it. Safe mode would certainly have reduced the impact from that script, and I'd definitely recommend turning it on unless you're very confident of the quality of all your scripts. However, some of the things in the exploit script were designed to let an attacker look at safe mode systems and possibly find another vulnerability. Certainly they'd have been able to get at any database/etc passwords used by the exploited website, possibly, depending on file system permissions, at most files belonging to the same user, even with safe mode on. This might then have let them find another way of attacking. -- Chris Those who do not remember the past are condemned to repeat it. Those who *do* remember the past don't get much choice either.
Re: crontab failure for daylight savings
On Tue, Oct 07, 2003 at 03:52:01PM +1300, Billy Naylor wrote: Thanks, i can confirm that /etc/default/rcS does have UTC=yes our hwclocks all show the same time as date.. fly:~# /sbin/hwclock Tue Oct 7 15:44:28 2003 -0.622797 seconds fly:~# date Tue Oct 7 15:44:30 NZDT 2003 Can other people take a look at their systems? Same here, doing a TZ=GMT hwclock gives the hardwareclock in GMT. Apparently, hwclock looks at your timezone and displays the clock in your timezone. Greetings, Chris Niekel -- I've been down so long, if I'd cheer up, I'd still be depressed. - Lisa Simpson, Moanin' Lisa Blues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: crontab failure for daylight savings
On Tue, Oct 07, 2003 at 03:52:01PM +1300, Billy Naylor wrote: Thanks, i can confirm that /etc/default/rcS does have UTC=yes our hwclocks all show the same time as date.. fly:~# /sbin/hwclock Tue Oct 7 15:44:28 2003 -0.622797 seconds fly:~# date Tue Oct 7 15:44:30 NZDT 2003 Can other people take a look at their systems? Same here, doing a TZ=GMT hwclock gives the hardwareclock in GMT. Apparently, hwclock looks at your timezone and displays the clock in your timezone. Greetings, Chris Niekel -- I've been down so long, if I'd cheer up, I'd still be depressed. - Lisa Simpson, Moanin' Lisa Blues.
Bug#198560: uw-imapd: uw-imapd operates on any file in the filesytem, not just mailboxes
Package: uw-imapd Version: 4:2001adebian-6 Severity: grave Tags: security, woody uw-imapd and uw-imapd-ssl are insecure by default. They allow a logged in user to retrieve or manipulate any file on the filesystem. This was discovered as a squirrelmail bug, but is actually a UW-IMAP bug. The exploits do not work on other IMAP servers. Note: This is only relevant on systems where users are not supposed to have shell access (ie email-only users). Other users would be able to access these files anyway. More information is here: http://www.securityfocus.com/bid/7952/exploit/ See this Squirrelmail-devel thread: http://sourceforge.net/mailarchive/forum.php?thread_id=2641998forum_id=7139 The UW-IMAP FAQ says that this is a known issue and reccomends a compile-time option to env_unix.c, setting restrictBox to prevent allowing users to access / and .. : http://www.washington.edu/imap/IMAP-FAQs/index.html#5.1 Please change this option for uw-imapd and uw-imapd-ssl. Thank you, -Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#198560: uw-imapd: uw-imapd operates on any file in the filesytem, not just mailboxes
Package: uw-imapd Version: 4:2001adebian-6 Severity: grave Tags: security, woody uw-imapd and uw-imapd-ssl are insecure by default. They allow a logged in user to retrieve or manipulate any file on the filesystem. This was discovered as a squirrelmail bug, but is actually a UW-IMAP bug. The exploits do not work on other IMAP servers. Note: This is only relevant on systems where users are not supposed to have shell access (ie email-only users). Other users would be able to access these files anyway. More information is here: http://www.securityfocus.com/bid/7952/exploit/ See this Squirrelmail-devel thread: http://sourceforge.net/mailarchive/forum.php?thread_id=2641998forum_id=7139 The UW-IMAP FAQ says that this is a known issue and reccomends a compile-time option to env_unix.c, setting restrictBox to prevent allowing users to access / and .. : http://www.washington.edu/imap/IMAP-FAQs/index.html#5.1 Please change this option for uw-imapd and uw-imapd-ssl. Thank you, -Chris
Re: recommendations for FTP server
Stephen Gran sent the following message Today: SG Hello all, SG SG I'd like the FTP server to not allow anonymous logins (which I assume SG most can do), chroot users to their home directories, and have some sort SG of encrypted connections (over SSL would be nice). I have thought about SG just using sftp, but currently ssh connections are rerouted to another SG box on the LAN, and I'd like to leave that set up as is, if possible. SG SG I see that proftpd is the example used in the 'securing Debian' manual, SG but it doesn't appear to be able to use SSL. OTOH, ftpd-ssl doesn't SG appear to do chroot'ing, at least not at a quick glance. Anybody know SG of one that combines these features? I suppose there is always stunnel, SG although I have never tried to use it for FTP. Install SSH and give your friends shell accounts. SFTP is a drop-in replacement for FTP. Generally, I never use FTP except to make anonymous downloads available. There have been too many problems with many FTP servers in the past. Adding SSL to a standard FTP session also presents the problem that many standard FTP clients (at least on Windows) do not support this configuration. -- Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University caldwell @ gwu . edu | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://asclepius.tops.gwu.edu | GPG key ID: 0xE52D0BE8 Formal education can rarely improve the character of a scoundrel. - Derek Bok, Harvard University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nautilus and portmapper port 111
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Wüst sent the following message Today: AW No matter if I try netstat -apn or netstat -atunp as someone pointed out AW in private, it gives the same result as netstat -tu -l -ee -p, apart AW from the established connections, namely there is nothing listening in AW port 111. Have you tried rpcinfo -p localhost to see if Nautilus is registering a connection to portmap? The newer Gnome installs (gnomevfs) depend on fam, which depends on portmap. I don't believe there is a direct dependency from core Nautilus to portmap, but possibly some of the Nautilus extras or vfs extrase are causing the dependency. - -- Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University caldwell @ gwu . edu | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://asclepius.tops.gwu.edu | GPG key ID: 0xE52D0BE8 Formal education can rarely improve the character of a scoundrel. - Derek Bok, Harvard University -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+5kId1YKAfuUtC+gRAiWJAJ9Cpr8WyWV061ppN9m6O1OXRmW9jwCfQHcl AWB5FF7DcvK7wMCroRqdn5M= =iqMD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN gateway
Daniel Kobras sent the following message Today: DK It's definitely not compatible on its own. I asked Cisco support, and DK they told me that it _might_ work when running freeswan on top of l2tp. DK Didn't get me much further, though. If someone else manages to figure it DK out, please let me know. :) DK Haven't had time to try this out with our VPN concentrator yet, but I did find this: http://www.cloudchaser.net/linux/Freeswan_Cisco_howto.txt -- Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University caldwell @ gwu . edu | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://asclepius.tops.gwu.edu | GPG key ID: 0xE52D0BE8 Formal education can rarely improve the character of a scoundrel. - Derek Bok, Harvard University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN gateway
Daniel Kobras sent the following message Today: DK It's definitely not compatible on its own. I asked Cisco support, and DK they told me that it _might_ work when running freeswan on top of l2tp. DK Didn't get me much further, though. If someone else manages to figure it DK out, please let me know. :) DK Haven't had time to try this out with our VPN concentrator yet, but I did find this: http://www.cloudchaser.net/linux/Freeswan_Cisco_howto.txt -- Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University caldwell @ gwu . edu | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://asclepius.tops.gwu.edu | GPG key ID: 0xE52D0BE8 Formal education can rarely improve the character of a scoundrel. - Derek Bok, Harvard University
Re: Why PHP is parsing not only .php
This is expected behaviour... Please see the secion about files with multiple extensions on the page http://httpd.apache.org/docs/mod/mod_mime.html#addencoding --- If more than one extension is given which maps onto the same type of meta-information, then the one to the right will be used. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html. --- You should probably be using the phps extension with the AddType application/x-httpd-php-source .phps instead of renameing them to have a .txt extension. Chris --- Yoss [EMAIL PROTECTED] wrote: Hello. Please, take a look at this: http://www.milc.com.pl/aa.php.txt Why PHP is parsing file with .php.txt extension? I think that is a security hole, because in easy way we can imagine that thereis php script that should allow to upload only .txt files. 99% of coders will check this with /.+?\.txt$/ because this is logic, that php script is everything what ends with .php. Is there any way to prevent such a situation that not only /.+?\.php/ is parsed by PHP? If you need any additional informations (config files, or something) let me know, I will send it with pleasure. -- Bart³omiej Butyn aka Yoss Nie ma tego z³ego co by na gorsze nie wysz³o. -- 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: Why PHP is parsing not only .php
This is expected behaviour... Please see the secion about files with multiple extensions on the page http://httpd.apache.org/docs/mod/mod_mime.html#addencoding --- If more than one extension is given which maps onto the same type of meta-information, then the one to the right will be used. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html. --- You should probably be using the phps extension with the AddType application/x-httpd-php-source .phps instead of renameing them to have a .txt extension. Chris --- Yoss [EMAIL PROTECTED] wrote: Hello. Please, take a look at this: http://www.milc.com.pl/aa.php.txt Why PHP is parsing file with .php.txt extension? I think that is a security hole, because in easy way we can imagine that thereis php script that should allow to upload only .txt files. 99% of coders will check this with /.+?\.txt$/ because this is logic, that php script is everything what ends with .php. Is there any way to prevent such a situation that not only /.+?\.php/ is parsed by PHP? If you need any additional informations (config files, or something) let me know, I will send it with pleasure. -- Bart³omiej Butyn aka Yoss Nie ma tego z³ego co by na gorsze nie wysz³o. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Consensus
I am someone who rarely (if ever) posts to this list. What Ted and Thomas have said is reasonable. It's not a major problem to anyone here to filter an email if they don't want to see off topic messages. Just make it clear it's off topic. I suggest the [OT] tag is appropriate. It's better than ignoring it and just posting any old topic. It's also better than having a moderated list. I dislike filtering on OT: because I think some real messages might get filtered. -Chris -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Consensus
I am someone who rarely (if ever) posts to this list. What Ted and Thomas have said is reasonable. It's not a major problem to anyone here to filter an email if they don't want to see off topic messages. Just make it clear it's off topic. I suggest the [OT] tag is appropriate. It's better than ignoring it and just posting any old topic. It's also better than having a moderated list. I dislike filtering on OT: because I think some real messages might get filtered. -Chris -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: Report to Recipient(s)
On 0, SCVBNOTES/SCVB/[EMAIL PROTECTED] wrote: Incident Information:- ---SNIP A BUNCH OF NAMES--- Message from Paul [EMAIL PROTECTED] was quarantined because it contained banned content. I would like to personally thank you for saving my soul from the banned content. Thanks, Chris pgpq4t99Uy6Y8.pgp Description: PGP signature
Re: Report to Recipient(s)
On 0, SCVBNOTES/SCVB/[EMAIL PROTECTED] wrote: Incident Information:- ---SNIP A BUNCH OF NAMES--- Message from Paul [EMAIL PROTECTED] was quarantined because it contained banned content. I would like to personally thank you for saving my soul from the banned content. Thanks, Chris pgp0.pgp Description: PGP signature
Re: how to identify the superuser in C
Well what happened is I secrued up and sent it to just Oohara and not to the list. Well I tried but sent it to [EMAIL PROTECTED] So that not working I opened it out of my sent items and just forwarded it to the list but the singing got screwed up. Chirs On Wed, 2002-12-11 at 06:14, Adrian 'Dagurashibanipal' von Bidder wrote: On Wed, 2002-12-11 at 03:58, Chris Shafer wrote: Hello, Some documentation I found helpful when I was doing something similar in [...] Just wondering... Content-Type: multipart/mixed instead of multipart/signed. Your mailer buggy? cheers -- vbi -- featured link: http://fortytwo.ch/smtp signature.asc Description: This is a digitally signed message part
Re: how to identify the superuser in C
Well what happened is I secrued up and sent it to just Oohara and not to the list. Well I tried but sent it to [EMAIL PROTECTED] So that not working I opened it out of my sent items and just forwarded it to the list but the singing got screwed up. Chirs On Wed, 2002-12-11 at 06:14, Adrian 'Dagurashibanipal' von Bidder wrote: On Wed, 2002-12-11 at 03:58, Chris Shafer wrote: Hello, Some documentation I found helpful when I was doing something similar in [...] Just wondering... Content-Type: multipart/mixed instead of multipart/signed. Your mailer buggy? cheers -- vbi -- featured link: http://fortytwo.ch/smtp signature.asc Description: This is a digitally signed message part
Re: how to identify the superuser in C
Hello, Some documentation I found helpful when I was doing something similar in a little game I was making. http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_25.html#SEC429 Chris Shafer Live Slow. Sail Fast On Tue, 2002-12-10 at 21:07, Oohara Yuuma wrote: I am working on adding a high score list to a game written in C. (It's already packaged.) The high score list will be 664 root:games and the game binary will be sgid games --- nothing special here. I want to dump and undump the list. Allowing everyone to undump the list will lead to cheating or even security problems, so I want to make sure that only the superuser may undump. Since the binary is sgid, some check is necessary before trying to write the list. The problem is that there is fakeroot. getuid() == 0 or geteuid() == 0 is not enough. PAM is an overkill. I think seteuid(0) == 0 is the best approach. Any opinion? -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 smile to answer --- Treasure, Radiant Silvergun, attitude #3 for SBS-130 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: how to identify the superuser in C
Hello, Some documentation I found helpful when I was doing something similar in a little game I was making. http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_25.html#SEC429 Chris Shafer Live Slow. Sail Fast On Tue, 2002-12-10 at 21:07, Oohara Yuuma wrote: I am working on adding a high score list to a game written in C. (It's already packaged.) The high score list will be 664 root:games and the game binary will be sgid games --- nothing special here. I want to dump and undump the list. Allowing everyone to undump the list will lead to cheating or even security problems, so I want to make sure that only the superuser may undump. Since the binary is sgid, some check is necessary before trying to write the list. The problem is that there is fakeroot. getuid() == 0 or geteuid() == 0 is not enough. PAM is an overkill. I think seteuid(0) == 0 is the best approach. Any opinion? -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 smile to answer --- Treasure, Radiant Silvergun, attitude #3 for SBS-130 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[OT] secure, minimal Debian installation for linux-based thin clients?
This is unrelated to any security patches / exploits, hence off-topic. I'm posting here mostly because it seems like the right crowd for this sort of problem. If this offends you, let me know and I'll find a different venue in the future. OK. We're a large network running lots (~100) thin clients, and expecting to run more of them in the future. Currently, these are NeoWare Eon's (mobile x86 cpu) running Linux (an old scaled-down RedHat), with an NFS-mounted root fs. They run almost nothing locally: currently an X server, sshd, and possibly some music forwarding daemon in the future, so users can listen to tunes on their thin clients using software on the server (we don't give users access to the local software). Now, we're looking to upgrade the Linux on these thin clients. I like Debian, so that's one obvious choice. However, a standard Debian install (e.g. what I run on my machine) gives us much more than we need. This isn't fatal, since the filesystem is NFS-mounted, but it's not clean, either. Is there a Debian-derived minimal distribution? Or should we just install the base Debian system, add X via tasksel, and add/remove remaining items with dselect or apt-get? There is obviously more than one solution here, so I'm looking for recommendations. We care about security; we don't want to run any services we don't need, etc. Reliability is key, so your uncle's friend's brother's alpha software might not be for us. Any other comments (relevant to Debian on thin clients / X terminals) welcome. -chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] secure, minimal Debian installation for linux-based thin clients?
OK, thanks. BTW, how does that differ from running tasksel and not selecting any tasks? Or is that even possible? -chris Noah L. Meyerhans [EMAIL PROTECTED] writes: On Fri, Oct 18, 2002 at 12:41:37PM -0700, Chris Majewski wrote: Now, we're looking to upgrade the Linux on these thin clients. I like Debian, so that's one obvious choice. However, a standard Debian install (e.g. what I run on my machine) gives us much more than we need. Towards the end of the Debian installation process, when you're asked whether you want to run tasksel or dselect, you can choose dselect and exit it before installing any packages. If you do that, you're left with a really minimal install. You might be able to base your work on this. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OT] secure, minimal Debian installation for linux-based thin clients?
This is unrelated to any security patches / exploits, hence off-topic. I'm posting here mostly because it seems like the right crowd for this sort of problem. If this offends you, let me know and I'll find a different venue in the future. OK. We're a large network running lots (~100) thin clients, and expecting to run more of them in the future. Currently, these are NeoWare Eon's (mobile x86 cpu) running Linux (an old scaled-down RedHat), with an NFS-mounted root fs. They run almost nothing locally: currently an X server, sshd, and possibly some music forwarding daemon in the future, so users can listen to tunes on their thin clients using software on the server (we don't give users access to the local software). Now, we're looking to upgrade the Linux on these thin clients. I like Debian, so that's one obvious choice. However, a standard Debian install (e.g. what I run on my machine) gives us much more than we need. This isn't fatal, since the filesystem is NFS-mounted, but it's not clean, either. Is there a Debian-derived minimal distribution? Or should we just install the base Debian system, add X via tasksel, and add/remove remaining items with dselect or apt-get? There is obviously more than one solution here, so I'm looking for recommendations. We care about security; we don't want to run any services we don't need, etc. Reliability is key, so your uncle's friend's brother's alpha software might not be for us. Any other comments (relevant to Debian on thin clients / X terminals) welcome. -chris
Re: [OT] secure, minimal Debian installation for linux-based thin clients?
OK, thanks. BTW, how does that differ from running tasksel and not selecting any tasks? Or is that even possible? -chris Noah L. Meyerhans [EMAIL PROTECTED] writes: On Fri, Oct 18, 2002 at 12:41:37PM -0700, Chris Majewski wrote: Now, we're looking to upgrade the Linux on these thin clients. I like Debian, so that's one obvious choice. However, a standard Debian install (e.g. what I run on my machine) gives us much more than we need. Towards the end of the Debian installation process, when you're asked whether you want to run tasksel or dselect, you can choose dselect and exit it before installing any packages. If you do that, you're left with a really minimal install. You might be able to base your work on this. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html
Re: AW: export problems on security updates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, I was not trying to make any specific statement about non-US cryptography law - I have no details on any specifics. I was just making a generalized statement that local law should apply rather than US law. BTW, What ever happened to the EU urging citizens to use cryptography because of ECHELON? Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University [EMAIL PROTECTED] | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://hippocrates.tops.gwu.edu | GPG key ID: 0xE52D0BE8 -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. - Richard Cook On Thu, 10 Oct 2002, Marcel Weber wrote: I think he meant France with the limitation of 56 bit encription. Marcel PGP / GPG Key:http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -Ursprungliche Nachricht- Von: Javier Fernandez-Sanguino Pena [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 10. Oktober 2002 15:24 An: Chris Caldwell Cc: Debian Security Betreff: Re: export problems on security updates? What might concern you is Spanish law regarding the use/import of cryptography. Which law might that be? Last I checked there was none. Javi -- 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9pYsa1YKAfuUtC+gRAui8AKDZGj4YiyhJ9V7akgh5a4NCpFrK0QCfT/FM exobQ9+iK7uwu79Pc7qYK94= =grGq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AW: export problems on security updates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, I was not trying to make any specific statement about non-US cryptography law - I have no details on any specifics. I was just making a generalized statement that local law should apply rather than US law. BTW, What ever happened to the EU urging citizens to use cryptography because of ECHELON? Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University [EMAIL PROTECTED] | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://hippocrates.tops.gwu.edu | GPG key ID: 0xE52D0BE8 -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. - Richard Cook On Thu, 10 Oct 2002, Marcel Weber wrote: I think he meant France with the limitation of 56 bit encription. Marcel PGP / GPG Key:http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -Ursprungliche Nachricht- Von: Javier Fernandez-Sanguino Pena [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 10. Oktober 2002 15:24 An: Chris Caldwell Cc: Debian Security Betreff: Re: export problems on security updates? What might concern you is Spanish law regarding the use/import of cryptography. Which law might that be? Last I checked there was none. Javi -- 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9pYsa1YKAfuUtC+gRAui8AKDZGj4YiyhJ9V7akgh5a4NCpFrK0QCfT/FM exobQ9+iK7uwu79Pc7qYK94= =grGq -END PGP SIGNATURE-
Re: export problems on security updates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My understanding is that the law restricts U.S. citizens from exporting certain types of cryptographic software. As a non-US national, I believe you have a moral responsibility to thumb your nose at US law. What might concern you is Spanish law regarding the use/import of cryptography. In any case, security updates are usually bug-fixes, not security software, per se. Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University [EMAIL PROTECTED] | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://hippocrates.tops.gwu.edu | GPG key ID: 0xE52D0BE8 -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. - Richard Cook On Wed, 9 Oct 2002, Alberto Cortés wrote: On http://security.debian.org/ it can be read: You can use apt to easily get the latest security updates. This requires a line such as deb http://security.debian.org/ woody/updates main contrib non-free Since I am not living in the US, and some security updates deals with cryptographic software, I understand that it will be illegal for me downloading these updates from outside of the USA. In other words, is http://security.debian.org/ located outside the US?. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9pKGo1YKAfuUtC+gRAtvwAJ46YE1v7dMqPqGnOGEmQ+WRG3gwcQCgm+nQ +/WmVX/hmQbV/xBR9MA8xM8= =je9M -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: export problems on security updates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My understanding is that the law restricts U.S. citizens from exporting certain types of cryptographic software. As a non-US national, I believe you have a moral responsibility to thumb your nose at US law. What might concern you is Spanish law regarding the use/import of cryptography. In any case, security updates are usually bug-fixes, not security software, per se. Chris Caldwell Information Systems Coordinator, Enterprise Systems Information Systems and Services, The George Washington University [EMAIL PROTECTED] | +1 202.994.4674 (w) | +1 202.409.0878 (c) http://hippocrates.tops.gwu.edu | GPG key ID: 0xE52D0BE8 -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. - Richard Cook On Wed, 9 Oct 2002, Alberto Cortés wrote: On http://security.debian.org/ it can be read: You can use apt to easily get the latest security updates. This requires a line such as deb http://security.debian.org/ woody/updates main contrib non-free Since I am not living in the US, and some security updates deals with cryptographic software, I understand that it will be illegal for me downloading these updates from outside of the USA. In other words, is http://security.debian.org/ located outside the US?. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9pKGo1YKAfuUtC+gRAtvwAJ46YE1v7dMqPqGnOGEmQ+WRG3gwcQCgm+nQ +/WmVX/hmQbV/xBR9MA8xM8= =je9M -END PGP SIGNATURE-
Re: Debian (Unstable) problem with SSH and PAM
On Thu, Oct 03, 2002 at 09:32:30PM +0200, Statu Nascendi wrote: btw... does anyone have a conf file for apt-proxy? a working one for woody - full option: main. contrib, non-free, non-US, security... i tried to make one, but didn't work like i expected and time is an issue for me here. Grab the latest version from sarge (it'll install on Woody), which contains a full apt-proxy.conf with lots of examples. Or go to the CVS link at http://apt-proxy.sf.net and look at apt-proxy.conf there. Chris pgpPD4uEHtI0M.pgp Description: PGP signature
Re: Debian (Unstable) problem with SSH and PAM
On Thu, Oct 03, 2002 at 09:32:30PM +0200, Statu Nascendi wrote: btw... does anyone have a conf file for apt-proxy? a working one for woody - full option: main. contrib, non-free, non-US, security... i tried to make one, but didn't work like i expected and time is an issue for me here. Grab the latest version from sarge (it'll install on Woody), which contains a full apt-proxy.conf with lots of examples. Or go to the CVS link at http://apt-proxy.sf.net and look at apt-proxy.conf there. Chris msg07196/pgp0.pgp Description: PGP signature
apache access log
hi, i have a woody-box here with apache 1.3.26 (.deb-package) today i discovered some strange log-entries in access.log that look like this: 80.142.57.69 - - [25/Sep/2002:04:57:59 +0200] \xe3N 302 0 - - ... 217.83.69.31 - - [25/Sep/2002:05:21:50 +0200] \xe3L 302 0 - - ... 80.144.33.142 - - [25/Sep/2002:11:05:44 +0200] \xe3D 302 0 - - 80.142.57.69 - - [25/Sep/2002:11:23:00 +0200] \xe3N 302 0 - - i'm no pro when it comes to apache, but is this something i should worry about? or just another script-kid? thx, .chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apache access log
hi, i have a woody-box here with apache 1.3.26 (.deb-package) today i discovered some strange log-entries in access.log that look like this: 80.142.57.69 - - [25/Sep/2002:04:57:59 +0200] \xe3N 302 0 - - ... 217.83.69.31 - - [25/Sep/2002:05:21:50 +0200] \xe3L 302 0 - - ... 80.144.33.142 - - [25/Sep/2002:11:05:44 +0200] \xe3D 302 0 - - 80.142.57.69 - - [25/Sep/2002:11:23:00 +0200] \xe3N 302 0 - - i'm no pro when it comes to apache, but is this something i should worry about? or just another script-kid? thx, .chris
Problems using the grsecurity kernel source patch package in woody.
Hello all, I'm trying to update the kernel on my woody box with the grsecurity patch package. I installed the 2.4.18 source package and the grsecurity patch package and untared the kernel source. After configuring it to my taste and setting patch_the_kernel := true in /etc/kernel-pkg.conf, make-kpkg buildpackage fails with the errors included at the end of this email, near what looks like the end of the process. Neither google nor the mailing list archives yielded any useful information. Has anyone seen this behavior before? -- --Chris Practice allows me to receive information like faxes. Pharoahe Monch chmod -R og=rX debian/tmp-source chown -R root.root debian/tmp-source (cd debian/tmp-source/usr/src/; \ tar --bzip2 -cf kernel-source-2.4.18-grsec-1.9.4.tar.bz2 kernel-source-2.4.18-grsec-1.9.4;\ rm -rf kernel-source-2.4.18-grsec-1.9.4;) dpkg-gencontrol -isp -pkernel-source-2.4.18-grsec-1.9.4 -Pdebian/tmp-source/ dpkg-gencontrol: error: package kernel-source-2.4.18-grsec-1.9.4 not in control info make[2]: *** [real_stamp_source] Error 29 make[2]: Leaving directory `/usr/src/kernel-source-2.4.18' make[2]: Entering directory `/usr/src/kernel-source-2.4.18' The changelog says we are creating 2.4.18, but I thought the version is 2.4.18-grsec-1.9.4 make[2]: *** [real_stamp_doc] Error 1 make[2]: Leaving directory `/usr/src/kernel-source-2.4.18' make[2]: Entering directory `/usr/src/kernel-source-2.4.18' The changelog says we are creating 2.4.18, but I thought the version is 2.4.18-grsec-1.9.4 make[2]: *** [real_stamp_image] Error 1 make[2]: Leaving directory `/usr/src/kernel-source-2.4.18' make[2]: Entering directory `/usr/src/kernel-source-2.4.18' The changelog says we are creating 2.4.18, but I thought the version is 2.4.18-grsec-1.9.4 make[2]: *** [real_stamp_headers] Error 1 make[2]: Leaving directory `/usr/src/kernel-source-2.4.18' make[1]: Leaving directory `/usr/src/kernel-source-2.4.18' dpkg-genchanges -mUnknown Kernel Package Maintainer [EMAIL PROTECTED] dpkg-genchanges: failure: cannot read files list file: No such file or directory make: *** [stamp-buildpackage] Error 2
[translation] NIS and propagation of groups
On Thu, 2002-06-20 at 08:28, Sebastien Picard wrote: Hi all, I'm using NIS 3.9-6 on woody (kernel 2.4.18). I'd like to know how to make the gids 1000 propagate, and not those 1000. The problem appeared after an update with an upgrade from potato to woody. Thank you in advance to any and all who reply. Have a nice evening :-) -- Chris Boyle - Winchester College - http://archives.wincoll.ac.uk/~chrisb/ GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961, AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on openprojects.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [translation] NIS and propagation of groups
This should probably have gone to the lists and the poster, not me. On Thu, 2002-06-20 at 15:02, Bertrand Orvoine wrote: see in /var/yp/Makefile : # We do not put password entries with lower UIDs (the root and system # entries) in the NIS password database, for security. MINUID is the # lowest uid that will be included in the password maps. # MINGID is the lowest gid that will be included in the group maps. MINUID=1000 MINGID=1000 it was 100 in potato. -- Chris Boyle - Debian Developer - aewm++, sapphire, xmmsarts GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961, AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on openprojects.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ROUTEUR ET IDENTD
I have been reading this thread as it comes into my mail and
suddenly I have an idea...
I don't mean this to be sarcastic.
.. it may have been attempted or may already exist - I am
internationally ignorant, though wish I were not so
.. why do we not have an RFC that documents the Official
(Written/Typed) Language of Communications for the World - On the
Internet?
Would we have an internet if we had not found a way to formalize the
way we communicate?
Ignore me if you think I am silly - but I would learn a new language
.. like Latin it would largly be a written language, but in time it
could be spoken.
If you know that this already exists I would love to know what the
number is. :-{}
Chris Lewis
- Original Message -
From: Gerd Koslowski [EMAIL PROTECTED]
To: 'Risto Jouhki' [EMAIL PROTECTED]; 'VERBEEK, Francois'
[EMAIL PROTECTED]
Cc: debian-security@lists.debian.org; 'suardi aurelien'
[EMAIL PROTECTED]
Sent: Saturday, June 08, 2002 7:51 AM
Subject: RE: ROUTEUR ET IDENTD
Hi,
Please allow me some additional remarks:
In the middle age and before the universal language was Latin, then
the
language of the diplomats was French. Now we live in a world where
English seems to be the language of science and economics. In Africa
there are still other languages that are used for trading and I
think
the majority of the humans have Chinese as the mother language.
It is not easy to find a common language, but it simplifies a lot in
our
global community to be able to communicate with each other. My
mother
language is German. Shall I ask that we speak German on
international
lists because I know this language best? By the way, I could have
also
written this mail in French. It is so many misunderstanding and
problems
between the peoples of the world besides different interests. We
should
adopt some language as the common denominator and our world will
become
a lot more peaceful. It is not important which language, but because
most people in the western world speak at least some English it is
good
that we agree on English. As it was with Latin, it does not mean and
is
not intended to suppress somebody's culture to demand to communicate
in
a different language than the mother language on international
lists.
---
Mit freundlichen Gruessen,
with kind regards,
Gerd Koslowski
-Original Message-
From: Risto Jouhki [mailto:[EMAIL PROTECTED]
Sent: Friday, June 07, 2002 11:01 PM
To: VERBEEK, Francois
Cc: 'debian-security@lists.debian.org'; 'suardi aurelien'
Subject: RE: ROUTEUR ET IDENTD
Hei
Voisitko kääntää tuon Ranskan Englanniksi, siksi kun tämän pitäisi
olla
Englannin kielinen internationillinen sähköposti-lista ?
Gætirðu vinsamlegast þýtt spurninguna á Ensku þar sem þetta á að
heita
enkumælandi e-mail listi?
= Could you please translate Your question to english, because this
is/should be an english speaking list.
Point is: Just to be able to communicate betveen many countries and
peoble
who don´t speak othervise the same language.
I could go to finnish or icelandic speking lists but ended here,
this is
just a kind of work-language for me.
Maybe we switch to japanese or chinese some day, who knows :)))
Kveðja / Regards
Risto Jouhki
Íslandssími GSM
Sóltúni 26
105 Reykjavík
Iceland
Mobile: +354 820 0275
Fax: +354 595 5199
VERBEEK,
FrancoisTo: 'suardi
aurelien' [EMAIL PROTECTED],
Francois.VERBEEK
'debian-security@lists.debian.org'
debian-security@lists.debian.org
@BBL.BE cc:
Subject: RE: ROUTEUR
ET
IDENTD
07.06.2002 13:51
1ere remarque : ça ne se fait pas d'envoyer une question pareille
sur
autant de mailing-lists à la fois.
2eme remarque : sur les listes internationales, on parle anglais,
sous
peine de ne pas se faire comprendre (et de ne pas recevoir de
réponse)
3eme remarque : l'orthographe ne doit pas être parfaite mais parfois
ça
sert à être mieux compris, et son absence totale peut déranger.
Cela dit, le routeur fait-il du NAT? (Masquerade) Auquel cas c'est
normal
que le squid fasse la requete ident sur le routeur : c'est cette
addresse
IP-là qu'il voit venir.
Je conseille une identification simple (user/pass) ou NTLM (voir
site de
squid) si les machines sont toutes sous window$.
-Original Message-
From: suardi aurelien
[SMTP:[EMAIL PROTECTED]
Sent: vendredi 7 juin 2002 15:07
To: debian-www-cvs@lists.debian.org;
debian-www@lists.debian.org; debian-user-french@lists.debian.org;
debian-user@lists.debian.org; debian-toolchain@lists.debian.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
debian-security@lists.debian.org; debian-perl@lists.debian.org;
debian-news@lists.debian.org; debian-l10n-french@lists.debian.org;
debian-kde
Re: ROUTEUR ET IDENTD
It would be convenient for me to agree to US English as a standard since that is what I know. Though a Canadian I prefer the American spelling of words. I think it would be cumbersom, but I am fluent in 'c', as suggested by another note. While I did not articulate it well, I was suggesting a language devised from usage, agreement, consensus reality - sharing. A kind of mix of languages -- formalized in a standard that was viewable, readable by everyone. There are too many different languages to learn them all and so I learn none other than my own. I would have to say yes, partially, to all of the other languages suggested, especially Esperanto but since we are not using them something must obviously be missing. I am not very familiar with these languages either -- I have been lazy. I suppose the reason that I questioned it at all is that I do not know how to justify English as the standard. I have noticed recently that language is more deeply bound to thought than I had realized. ... sorry sounds a little too much like 1984. There is a part of me that likes to invent new words -- currently they are only my words because no one else knows what they mean. Chris Lewis Thanks for the info. - Original Message - From: Thomas Thurman [EMAIL PROTECTED] To: Chris Lewis [EMAIL PROTECTED] Cc: debian-security@lists.debian.org Sent: Saturday, June 08, 2002 3:26 PM Subject: Re: ROUTEUR ET IDENTD On Sat, 8 Jun 2002, Chris Lewis wrote: I don't mean this to be sarcastic. .. it may have been attempted or may already exist - I am internationally ignorant, though wish I were not so .. why do we not have an RFC that documents the Official (Written/Typed) Language of Communications for the World - On the Internet? Are you suggesting an RFC that says Unless otherwise stated, all communication on the Internet should be in US English, or something? Or do you mean that the RFC would propose the use of an auxlang such as Interlingua, Glosa, Ido or Esperanto? Or do you propose an RFC describing a new auxlang designed specially for the purpose? The IETF has said that English is the language used for RFCs[1], incidentally, though that's a long way from any of the interpretations of your question given above. T [1] http://www.rfc-editor.org/overview.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPG subkeys and keyservers
My gpg encryption subkey expired recently; I created a new subkey; it's signed, expires in a few months, etc. The key imports fine when I pull it in from the ascii armored export version ... but exporting it to the keyserver via --send-key fails miserably. I get a report of success, but when I --recv-key, I don't get the new subkey. (below: my public/private keypair resides on meteu. fury is another host, which does not have either key.) meteu:~ 2% gpg --send-key flip gpg: success sending to `wwwkeys.us.pgp.net' (status=200) meteu:~ 3% gpg --export -a flip /var/www/public.asc meteu:~ 4% gpg --list-key flip pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] meteu:~ 5% New subkey exists, supposedly got exported to wwwkeys.us.pgp.net alright. However. fury:~ 40% gpg --list-key flip gpg: Warning: using insecure memory! gpg: error reading key: public key not found fury:~ 41% wget http://meteu.octoraro.org/public.asc --11:46:10-- http://meteu.octoraro.org/public.asc = `public.asc' Connecting to meteu.octoraro.org:80... connected! HTTP request sent, awaiting response... 200 OK Length: 2,265 [text/plain] 0K .. 100% @ 44.24 KB/s 11:46:10 (44.24 KB/s) - `public.asc' saved [2265/2265] fury:~ 42% gpg --import public.asc gpg: Warning: using insecure memory! gpg: key 17984F07: public key imported gpg: Total number processed: 1 gpg: imported: 1 fury:~ 43% gpg --list-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] fury:~ 44% Key is imported just fine from the ascii armored export. No problems. fury:~ 44% gpg --delete-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] Delete this key from the keyring? yes fury:~ 45% gpg --list-key flip gpg: Warning: using insecure memory! gpg: error reading key: public key not found fury:~ 46% gpg --recv-key 17984F07 gpg: Warning: using insecure memory! gpg: requesting key 17984F07 from wwwkeys.us.pgp.net ... gpg: key 17984F07: public key imported gpg: Total number processed: 1 gpg: imported: 1 fury:~ 47% gpg --list-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] fury:~ 48% Apparently, the version of the key up on the PGP server doesn't have the new subkey. So, what am I missing? -- //[pgp] 1024D/17984F07 [http] meteu.octoraro.org Nice, selfless people don't restore my faith in humanity -- they restore my faith in randomness. msg06658/pgp0.pgp Description: PGP signature
GPG subkeys and keyservers
My gpg encryption subkey expired recently; I created a new subkey; it's signed, expires in a few months, etc. The key imports fine when I pull it in from the ascii armored export version ... but exporting it to the keyserver via --send-key fails miserably. I get a report of success, but when I --recv-key, I don't get the new subkey. (below: my public/private keypair resides on meteu. fury is another host, which does not have either key.) meteu:~ 2% gpg --send-key flip gpg: success sending to `wwwkeys.us.pgp.net' (status=200) meteu:~ 3% gpg --export -a flip /var/www/public.asc meteu:~ 4% gpg --list-key flip pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] meteu:~ 5% New subkey exists, supposedly got exported to wwwkeys.us.pgp.net alright. However. fury:~ 40% gpg --list-key flip gpg: Warning: using insecure memory! gpg: error reading key: public key not found fury:~ 41% wget http://meteu.octoraro.org/public.asc --11:46:10-- http://meteu.octoraro.org/public.asc = `public.asc' Connecting to meteu.octoraro.org:80... connected! HTTP request sent, awaiting response... 200 OK Length: 2,265 [text/plain] 0K .. 100% @ 44.24 KB/s 11:46:10 (44.24 KB/s) - `public.asc' saved [2265/2265] fury:~ 42% gpg --import public.asc gpg: Warning: using insecure memory! gpg: key 17984F07: public key imported gpg: Total number processed: 1 gpg: imported: 1 fury:~ 43% gpg --list-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] sub 1024g/BCA91458 2002-05-09 [expires: 2002-11-05] fury:~ 44% Key is imported just fine from the ascii armored export. No problems. fury:~ 44% gpg --delete-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] Delete this key from the keyring? yes fury:~ 45% gpg --list-key flip gpg: Warning: using insecure memory! gpg: error reading key: public key not found fury:~ 46% gpg --recv-key 17984F07 gpg: Warning: using insecure memory! gpg: requesting key 17984F07 from wwwkeys.us.pgp.net ... gpg: key 17984F07: public key imported gpg: Total number processed: 1 gpg: imported: 1 fury:~ 47% gpg --list-key flip gpg: Warning: using insecure memory! pub 1024D/17984F07 2001-10-06 Chris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] uidChris Flipse [EMAIL PROTECTED] sub 1024g/B03178DE 2001-10-06 [expires: 2002-04-04] fury:~ 48% Apparently, the version of the key up on the PGP server doesn't have the new subkey. So, what am I missing? -- //[pgp] 1024D/17984F07 [http] meteu.octoraro.org Nice, selfless people don't restore my faith in humanity -- they restore my faith in randomness. pgpBnn3rAbpLc.pgp Description: PGP signature
Re: Allow root to telnet
On Thu, Apr 18, 2002 at 11:28:28AM +0800, Michael Watts wrote: Hi, I am having trouble with a few services and want to allow root to telnet to a Debian 2.2r5 system for testing purposes, but can not find the way to allow this to happen. You really really really do not want to do this. You don't mention if the machine in question is on the internet, but regardless it's a bad idea. If you really must enable remote access, please consider using ssh instead. Generally speaking you never want to enable remote root logins, you should instead have a regular user account log in and then use su. I have had a look through the man pages, and looked into /etc/securetty but get stuck there. Do I have to add an entry for telnet to securetty to allow root to login that way? Yes, that is correct. By default /etc/securetty on most distributions only permits root logins from the console. I don't believe sshd observes /etc/securetty though, so if you decide to use ssh you'll want to take a look at the PermitRootLogin parameter. (And preferably set it to no) Also, how would I allow telnet to accessed on more than one port at a time. I may need to allow it on port 23 and (omniback backup software port), but can only seem to allow one or the other, not both. How can I allow both 23 and to accept telnet? A port can only be used by one application at a time. You can't have telnet and omniback listening to port together. There are a lot of unused ports available, is having telnet listen to, for example, an option? I hope this helps. Chris Hilts [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Allow root to telnet
On Thu, Apr 18, 2002 at 11:28:28AM +0800, Michael Watts wrote: Hi, I am having trouble with a few services and want to allow root to telnet to a Debian 2.2r5 system for testing purposes, but can not find the way to allow this to happen. You really really really do not want to do this. You don't mention if the machine in question is on the internet, but regardless it's a bad idea. If you really must enable remote access, please consider using ssh instead. Generally speaking you never want to enable remote root logins, you should instead have a regular user account log in and then use su. I have had a look through the man pages, and looked into /etc/securetty but get stuck there. Do I have to add an entry for telnet to securetty to allow root to login that way? Yes, that is correct. By default /etc/securetty on most distributions only permits root logins from the console. I don't believe sshd observes /etc/securetty though, so if you decide to use ssh you'll want to take a look at the PermitRootLogin parameter. (And preferably set it to no) Also, how would I allow telnet to accessed on more than one port at a time. I may need to allow it on port 23 and (omniback backup software port), but can only seem to allow one or the other, not both. How can I allow both 23 and to accept telnet? A port can only be used by one application at a time. You can't have telnet and omniback listening to port together. There are a lot of unused ports available, is having telnet listen to, for example, an option? I hope this helps. Chris Hilts [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
security updates for hppa
I'm new to debian linux, and I am having trouble finding the security updates for the HPPA system. I have looked all through http://security.debian.org/dists/ I found the updates for the other ports, but not hppa. Any thoughts on where I might find them or what to put in the sources.list file? I think I installed 'woody' from the 0.9.3 CD. I am also using the 32bit kernel. TIA, Chris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
security updates for hppa
I'm new to debian linux, and I am having trouble finding the security updates for the HPPA system. I have looked all through http://security.debian.org/dists/ I found the updates for the other ports, but not hppa. Any thoughts on where I might find them or what to put in the sources.list file? I think I installed 'woody' from the 0.9.3 CD. I am also using the 32bit kernel. TIA, Chris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote: All of this has gotten me to thinking about another flaw in the way I have things set up. I'm preventing users from getting to a $ by running a menu from their profile. exec /usr/bin/menu This works fine since the exec causes menu to become their shell process. But some smart user could get around this by using pscp to upload their own .bash_profile. Even if I fix it so I have them chroot'd on their home would not prevent this since this file is in their home. But changing permissions on the .bash_profile so they don't own it (and not in their group) should take care of that problem. They can read it all they want, just not change it. Why not change the users' shell to /usr/bin/menu? Bye, Chris -- http://www.tuxedo.org/~esr/faqs/smart-questions.html __ _ -o)/ / (_)__ __ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote: All of this has gotten me to thinking about another flaw in the way I have things set up. I'm preventing users from getting to a $ by running a menu from their profile. exec /usr/bin/menu This works fine since the exec causes menu to become their shell process. But some smart user could get around this by using pscp to upload their own .bash_profile. Even if I fix it so I have them chroot'd on their home would not prevent this since this file is in their home. But changing permissions on the .bash_profile so they don't own it (and not in their group) should take care of that problem. They can read it all they want, just not change it. Why not change the users' shell to /usr/bin/menu? Bye, Chris -- http://www.tuxedo.org/~esr/faqs/smart-questions.html __ _ -o)/ / (_)__ __ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
At 11:03 AM 1/21/2002, you wrote: On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. Cut from /etc/logrotate.d/mysql-server # If the root user has a password you have to create a # /root/.my.cnf configuration file with the following # content: Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
At 11:03 AM 1/21/2002, you wrote: On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. Cut from /etc/logrotate.d/mysql-server # If the root user has a password you have to create a # /root/.my.cnf configuration file with the following # content: Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Chris
Re: Re: How do I disable (close) ports?
On Wed, Dec 05, 2001 at 01:24:54PM +0100, J. Paul Bruns-Bielkowicz wrote: It seems to. The above ports were closed just by commenting them out of /etc/services and then rebooting. An init 1, init 3 would have worked as well. Correct me if I'm wrong here, but why would you comment things out of /etc/services? Try /etc/inetd.conf or /etc/xinetd.conf /etc/services just maps ports to service names. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: How do I disable (close) ports?
On Wed, Dec 05, 2001 at 01:24:54PM +0100, J. Paul Bruns-Bielkowicz wrote: It seems to. The above ports were closed just by commenting them out of /etc/services and then rebooting. An init 1, init 3 would have worked as well. Correct me if I'm wrong here, but why would you comment things out of /etc/services? Try /etc/inetd.conf or /etc/xinetd.conf /etc/services just maps ports to service names. Chris
Re: Re: How do I disable (close) ports?
On Wed, Dec 05, 2001 at 01:24:54PM +0100, J. Paul Bruns-Bielkowicz wrote: It seems to. The above ports were closed just by commenting them out of /etc/services and then rebooting. An init 1, init 3 would have worked as well. Correct me if I'm wrong here, but why would you comment things out of /etc/services? Try /etc/inetd.conf or /etc/xinetd.conf /etc/services just maps ports to service names. Chris
RE: Squid security
ACL's are avalible in squid, what you can do is setup an ACL to allow only your networks IP's to connect to squid, and deny everything else. like this: acl all src 0.0.0.0/0.0.0.0 acl private_networks0 src xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx acl private_networks1 src xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx and then, http_access allow private_networks0 http_access allow private_networks1 http_access deny all Pretty similar to a firewall rule setup, another security measure you can take is, if your squid proxy has multiple interfaces, like one public and one private, you can set the tcp_incoming_address and tcp_outgoing_address - this means squid won't actually listen on the external address, but will use it for external connections. Hope this is off assistance. Regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 5 December 2001 17:21 To: Debian Security Subject: Squid security Recently, I had someone trying to browse the web from one of our servers via squid. Luckily, I didn't need squid for this machine, so I took it off and emailed the hostmaster of the domain the person was doing it from..luckily the IP address was the same. i also managed to get the IP address blocked by our ISP. On another server, which I have squid running and want running, I keep getting accesses from http://service.bfast.com/bfast/serve and someone seems to be accessing web pages late at night when everyone has gone home. Trouble is, the IP addresses that access squid don't have host names (ie. they don't exist) and they keep changing. Is there any way to block access to this and is there a good FAQ, etc. It seems strange though, as the access is every few minutes and the pages accessed have ads involved,while the first person (above) was accessing squid regularly in spurts. Thanks Robert.. -- 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: How do I disable (close) ports?
Hi Paul, On Tue, Dec 04, 2001 at 09:18:09PM +0100, J. Paul Bruns-Bielkowicz wrote: Hi, I disabled all but a few ports in /etc/services, but I have tcp0 0 pa237.olsztyn.sdi.t:111 80.116.215.37:1064 ESTABLISHED when I netstat my machine. What exactly does this mean? I just want 25/tcp opensmtp 37/tcp opentime 66/tcp opensql*net 80/tcp openhttp 110/tcpopenpop-3 443/tcpopenhttps 3306/tcp openmysql open. How can I close ports 111 and 859? They are not enabled in /etc/services may you take a look at the corresponding man pages: services, inetd.conf and inetd: (services...) services is a plain ASCII file providing a mapping between friendly textual names for internet services, and their underlying assigned port numbers and protocol types. ... The presence of an entry for a service in the services file does not necessarily mean that the service is cur- rently running on the machine. See inetd.conf(5) for the configuration of Internet services offered. Note that not all networking services are started by inetd(8), and so won't appear in inetd.conf(5). In particular, news (NNTP) and mail (SMTP) servers are often initialised from the system boot scripts. ... A port is open if there is a programm listening on it and answering incomming requests. It has nothing to do whether it is mentioned in /etc/services or not. Hope this helps and fit your needs regards chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Squid security
ACL's are avalible in squid, what you can do is setup an ACL to allow only your networks IP's to connect to squid, and deny everything else. like this: acl all src 0.0.0.0/0.0.0.0 acl private_networks0 src xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx acl private_networks1 src xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx and then, http_access allow private_networks0 http_access allow private_networks1 http_access deny all Pretty similar to a firewall rule setup, another security measure you can take is, if your squid proxy has multiple interfaces, like one public and one private, you can set the tcp_incoming_address and tcp_outgoing_address - this means squid won't actually listen on the external address, but will use it for external connections. Hope this is off assistance. Regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 5 December 2001 17:21 To: Debian Security Subject: Squid security Recently, I had someone trying to browse the web from one of our servers via squid. Luckily, I didn't need squid for this machine, so I took it off and emailed the hostmaster of the domain the person was doing it from..luckily the IP address was the same. i also managed to get the IP address blocked by our ISP. On another server, which I have squid running and want running, I keep getting accesses from http://service.bfast.com/bfast/serve and someone seems to be accessing web pages late at night when everyone has gone home. Trouble is, the IP addresses that access squid don't have host names (ie. they don't exist) and they keep changing. Is there any way to block access to this and is there a good FAQ, etc. It seems strange though, as the access is every few minutes and the pages accessed have ads involved,while the first person (above) was accessing squid regularly in spurts. Thanks Robert.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I disable (close) ports?
Hi Paul, On Tue, Dec 04, 2001 at 09:18:09PM +0100, J. Paul Bruns-Bielkowicz wrote: Hi, I disabled all but a few ports in /etc/services, but I have tcp0 0 pa237.olsztyn.sdi.t:111 80.116.215.37:1064 ESTABLISHED when I netstat my machine. What exactly does this mean? I just want 25/tcp opensmtp 37/tcp opentime 66/tcp opensql*net 80/tcp openhttp 110/tcpopenpop-3 443/tcpopenhttps 3306/tcp openmysql open. How can I close ports 111 and 859? They are not enabled in /etc/services may you take a look at the corresponding man pages: services, inetd.conf and inetd: (services...) services is a plain ASCII file providing a mapping between friendly textual names for internet services, and their underlying assigned port numbers and protocol types. ... The presence of an entry for a service in the services file does not necessarily mean that the service is cur- rently running on the machine. See inetd.conf(5) for the configuration of Internet services offered. Note that not all networking services are started by inetd(8), and so won't appear in inetd.conf(5). In particular, news (NNTP) and mail (SMTP) servers are often initialised from the system boot scripts. ... A port is open if there is a programm listening on it and answering incomming requests. It has nothing to do whether it is mentioned in /etc/services or not. Hope this helps and fit your needs regards chris
