Re: systemd-resolved DNSSEC root trust anchor outdated ?
On 2019-01-12 9:36 a.m., Marc Deslauriers wrote: > On 2019-01-11 11:01 p.m., J Doe wrote: >> Hello, >> >> I currently run a server using Ubuntu 18.04.1 LTS with patches current to >> today (Jan 11, 2019). I configured systemd-resolved to use DNSSEC >> validation by editing: /etc/systemd/resolved.conf and setting: DNSSEC=yes. >> >> When I check my syslog, I note that systemd-resolved is logging that the >> positive trust anchor for the root has been revoked: >> >> Jan 11 17:59:48 server systemd-resolved[728]: DNSSEC Trust anchor . IN DS >> 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 >> has been revoked. Please update the trust anchor, or upgrade your operating >> system. >> >> I checked: man dnssec-trust-anchors.d and read: >> >> "Note that systemd-resolved will automatically use a built-in trust anchor >> key for the Internet root domain if no positive trust anchors are defined >> for the root domain.” >> >> I verified that: /etc/dnssec-trust-anchors.d/*.positive, >> /run/dnssec-trust-anchors.d/*.positive, >> /usr/lib/dnssec-trust-anchors.d/*.positive do *NOT* exist, which means that >> only the compiled in root trust anchor key is being used and that >> systemd-resolved has found that it has been revoked. >> >> Does this require a new root trust anchor to be compiled in and then shipped >> in a systemd update or should I manually acquire the root trust anchor and >> place it in one of the directories mentioned in: man dnssec-trust-anchors.d ? >> >> For the meantime, I have disabled DNSSEC validation in: >> /etc/systemd/resolved.conf >> >> Thanks, >> >> - J >> > > It looks like resolved in 18.04 does in fact contain both the old and new > trusty > anchors hardcoded in resolved-dns-trusty-anchor.c. A quick look at the file > suggests the expired one then gets removed from the list and the warning is > issued. > > Do you only get the warning once? > > Marc. > Wow, I managed to typo "trust" as "trusty" twice. Stupid muscle memory ;) Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: systemd-resolved DNSSEC root trust anchor outdated ?
On 2019-01-11 11:01 p.m., J Doe wrote: > Hello, > > I currently run a server using Ubuntu 18.04.1 LTS with patches current to > today (Jan 11, 2019). I configured systemd-resolved to use DNSSEC validation > by editing: /etc/systemd/resolved.conf and setting: DNSSEC=yes. > > When I check my syslog, I note that systemd-resolved is logging that the > positive trust anchor for the root has been revoked: > > Jan 11 17:59:48 server systemd-resolved[728]: DNSSEC Trust anchor . IN DS > 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 > has been revoked. Please update the trust anchor, or upgrade your operating > system. > > I checked: man dnssec-trust-anchors.d and read: > > "Note that systemd-resolved will automatically use a built-in trust anchor > key for the Internet root domain if no positive trust anchors are defined for > the root domain.” > > I verified that: /etc/dnssec-trust-anchors.d/*.positive, > /run/dnssec-trust-anchors.d/*.positive, > /usr/lib/dnssec-trust-anchors.d/*.positive do *NOT* exist, which means that > only the compiled in root trust anchor key is being used and that > systemd-resolved has found that it has been revoked. > > Does this require a new root trust anchor to be compiled in and then shipped > in a systemd update or should I manually acquire the root trust anchor and > place it in one of the directories mentioned in: man dnssec-trust-anchors.d ? > > For the meantime, I have disabled DNSSEC validation in: > /etc/systemd/resolved.conf > > Thanks, > > - J > It looks like resolved in 18.04 does in fact contain both the old and new trusty anchors hardcoded in resolved-dns-trusty-anchor.c. A quick look at the file suggests the expired one then gets removed from the list and the warning is issued. Do you only get the warning once? Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Request for package update for Bionic 18.04.1 LTS server
On 2018-11-06 8:13 a.m., Marc Deslauriers wrote: > On 2018-11-06 7:21 a.m., Marc Deslauriers wrote: >> Hi, >> >> On 2018-11-05 4:52 p.m., J Doe wrote: >>> Hello, >>> >>> Is this the appropriate list to make a request for an update to a package >>> for Bionic 18.04.1 LTS server ? The update in question is SpamAssassin >>> 3.4.2 which fixes 4 CVE’s [1] and was released on 2018-09-16. >>> >>> Thank you, >>> >>> - J >>> >>> Links: >>> >>> [1] https://spamassassin.apache.org/news.html >>> >> >> I have been working on updates to 3.4.2. They will be available in the >> security >> team PPA for testing withing the next hour: >> >> https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages >> >> Once they are available, I would appreciate feedback if they worked properly >> before I release them as official updates since we are bumping the version to >> 3.4.2 because of the signatures signing change. >> >> Updates are being tracked in the following bug: >> >> https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1796863 >> >> Thanks, >> >> Marc. >> > > Packages are now fully built and available in that PPA for testing. Please > comment in the bug I listed. Thanks! > > Marc. > Updates have now been published: https://usn.ubuntu.com/3811-1/ Thanks! Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Request for package update for Bionic 18.04.1 LTS server
On 2018-11-06 7:21 a.m., Marc Deslauriers wrote: > Hi, > > On 2018-11-05 4:52 p.m., J Doe wrote: >> Hello, >> >> Is this the appropriate list to make a request for an update to a package >> for Bionic 18.04.1 LTS server ? The update in question is SpamAssassin >> 3.4.2 which fixes 4 CVE’s [1] and was released on 2018-09-16. >> >> Thank you, >> >> - J >> >> Links: >> >> [1] https://spamassassin.apache.org/news.html >> > > I have been working on updates to 3.4.2. They will be available in the > security > team PPA for testing withing the next hour: > > https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages > > Once they are available, I would appreciate feedback if they worked properly > before I release them as official updates since we are bumping the version to > 3.4.2 because of the signatures signing change. > > Updates are being tracked in the following bug: > > https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1796863 > > Thanks, > > Marc. > Packages are now fully built and available in that PPA for testing. Please comment in the bug I listed. Thanks! Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Request for package update for Bionic 18.04.1 LTS server
Hi, On 2018-11-05 4:52 p.m., J Doe wrote: > Hello, > > Is this the appropriate list to make a request for an update to a package for > Bionic 18.04.1 LTS server ? The update in question is SpamAssassin 3.4.2 > which fixes 4 CVE’s [1] and was released on 2018-09-16. > > Thank you, > > - J > > Links: > > [1] https://spamassassin.apache.org/news.html > I have been working on updates to 3.4.2. They will be available in the security team PPA for testing withing the next hour: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages Once they are available, I would appreciate feedback if they worked properly before I release them as official updates since we are bumping the version to 3.4.2 because of the signatures signing change. Updates are being tracked in the following bug: https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1796863 Thanks, Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: Samba security updates
Hello, Today the Samba Team released updated Samba packages that fix the "Badlock" security issue, and additional related man-in-the-middle and denial-of-service issues: http://badlock.org/ Since the fixes for these issues are massive, and newer versions of Samba contain other interoperability and security improvements, we have decided to upgrade Ubuntu 14.04 LTS and Ubuntu 15.10 to Samba 4.3.8. For Ubuntu 12.04 LTS, we will be updating to 3.6.25 and adding backported fixes for these issues provided by Andreas Schneider, Ralph Böhme, Stefan Metzmacher, Günther Deschner and Aurélien Aptel. If you are running Samba in your environment, please backup your configuration and databases and help test the packages currently available in the security team PPA: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages These updated packages may introduce incompatible changes and may require configuration adjustments depending on your environment. Please report any regressions found in the following tracking bug: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1569497 If no issues are reported, we plan on releasing the packages as security updates in a week. Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Call for testing: QEMU security updates
Hi Simon, Thanks for testing it! Marc. On 14-08-14 03:49 PM, Simon Deziel wrote: > Hi Marc, > > I couldn't find any issue in the few testing scenarios I could try: > > 12.04: > * Basic testing using .raw and LVM with 1.0+noroms-0ubuntu14.17 > * Live migration: 1.0+noroms-0ubuntu14.16 -> .17 > * Live migration: 1.0+noroms-0ubuntu14.17 -> .16 > * Live migration: 1.0+noroms-0ubuntu14.17 -> .17 > > 14.04: > * Basic testing using LVM with 2.0.0+dfsg-2ubuntu1.3 > > Since most of my production is on 12.04, I'll keep migrating more VMs to > .17 and will report any eventual problem in LP. > > Thanks a lot Marc! > Simon > > On 08/14/2014 02:33 PM, Marc Deslauriers wrote: >> Hi, >> >> I have pushed updated qemu-kvm packages for Ubuntu 10.04 LTS and Ubuntu 12.04 >> LTS, and qemu packages for Ubuntu 14.04 LTS into the -proposed pocket. >> >> These packages fix a very large number of security issues regarding image >> format >> validation and state loading. Due to the large number of patches, I would >> appreciate getting additional testing from people who run qemu in various >> environments. >> >> See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how >> to enable and use -proposed. >> >> Please report any issues in the tracking bug: >> https://launchpad.net/bugs/1357018 >> >> If no issues are reported, I plan on releasing the packages as security >> updates in a couple of weeks. >> >> Here is the list of CVEs fixed in each release: >> >> 10.04 LTS: >> CVE-2014-0142, CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0146, >> CVE-2014-0147, CVE-2013-4148, CVE-2013-4151, CVE-2013-4530, CVE-2013-4531, >> CVE-2013-4533, CVE-2013-4534, CVE-2013-4537, CVE-2013-4538, CVE-2013-4539, >> CVE-2013-4540, CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, CVE-2014-0223 >> >> 12.04 LTS: >> CVE-2014-0142, CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0146, >> CVE-2014-0147, CVE-2013-4148, CVE-2013-4151, CVE-2013-4527, CVE-2013-4529, >> CVE-2013-4530, CVE-2013-4531, CVE-2013-4532, CVE-2013-4533, CVE-2013-4534, >> CVE-2013-4535, CVE-2013-4536, CVE-2013-4537, CVE-2013-4538, CVE-2013-4539, >> CVE-2013-4540, CVE-2013-4541, CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, >> CVE-2014-0223, CVE-2014-3461 >> >> 14.04 LTS: >> CVE-2013-4148, CVE-2013-4149, CVE-2013-4150, CVE-2013-4151, CVE-2013-4526, >> CVE-2013-4527, CVE-2013-4529, CVE-2013-4530, CVE-2013-4531, CVE-2013-4532, >> CVE-2013-4533, CVE-2013-4534, CVE-2013-4535, CVE-2013-4536, CVE-2013-4537, >> CVE-2013-4538, CVE-2013-4539, CVE-2013-4540, CVE-2013-4541, CVE-2013-4542, >> CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, CVE-2014-0223, CVE-2014-3461, >> CVE-2014-3471 >> >> Thanks, >> >> Marc. >> > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: QEMU security updates
Hi, I have pushed updated qemu-kvm packages for Ubuntu 10.04 LTS and Ubuntu 12.04 LTS, and qemu packages for Ubuntu 14.04 LTS into the -proposed pocket. These packages fix a very large number of security issues regarding image format validation and state loading. Due to the large number of patches, I would appreciate getting additional testing from people who run qemu in various environments. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Please report any issues in the tracking bug: https://launchpad.net/bugs/1357018 If no issues are reported, I plan on releasing the packages as security updates in a couple of weeks. Here is the list of CVEs fixed in each release: 10.04 LTS: CVE-2014-0142, CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0146, CVE-2014-0147, CVE-2013-4148, CVE-2013-4151, CVE-2013-4530, CVE-2013-4531, CVE-2013-4533, CVE-2013-4534, CVE-2013-4537, CVE-2013-4538, CVE-2013-4539, CVE-2013-4540, CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, CVE-2014-0223 12.04 LTS: CVE-2014-0142, CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0146, CVE-2014-0147, CVE-2013-4148, CVE-2013-4151, CVE-2013-4527, CVE-2013-4529, CVE-2013-4530, CVE-2013-4531, CVE-2013-4532, CVE-2013-4533, CVE-2013-4534, CVE-2013-4535, CVE-2013-4536, CVE-2013-4537, CVE-2013-4538, CVE-2013-4539, CVE-2013-4540, CVE-2013-4541, CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, CVE-2014-0223, CVE-2014-3461 14.04 LTS: CVE-2013-4148, CVE-2013-4149, CVE-2013-4150, CVE-2013-4151, CVE-2013-4526, CVE-2013-4527, CVE-2013-4529, CVE-2013-4530, CVE-2013-4531, CVE-2013-4532, CVE-2013-4533, CVE-2013-4534, CVE-2013-4535, CVE-2013-4536, CVE-2013-4537, CVE-2013-4538, CVE-2013-4539, CVE-2013-4540, CVE-2013-4541, CVE-2013-4542, CVE-2013-6399, CVE-2014-0182, CVE-2014-0222, CVE-2014-0223, CVE-2014-3461, CVE-2014-3471 Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: Updated ca-certificates package
Hi, I have pushed updated ca-certificates packages for Ubuntu 10.04 LTS, Ubuntu 12.04 LTS, Ubuntu 12.10 and Ubuntu 13.10 into the -proposed pocket. These packages will update the system CA certificates on stable releases to the latest version, and in the process will fix a multitude of open bugs. I would appreciate if these packages could get tested before I push them out as security updates. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. The packages fix the following bugs: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1257265 https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1258286 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1014640 https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1031333 https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1271357 Please report any issues by replying to this email, or by filing a new bug against the ca-certificates package. Make sure to specify the exact package version. If no issues are reported, I plan on releasing the packages as security updates in a couple of weeks. Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: MySQL 5.1.66 and 5.5.28 security updates
Hi, I have pushed updated MySQL 5.1.66 packages for Ubuntu 10.04 LTS and Ubuntu 11.10, and MySQL 5.5.28 for Ubuntu 12.04 LTS and Ubuntu 12.10 into the -proposed pocket. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. The packages fix the following security issues: http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html Please report any issues in the tracking bug: https://launchpad.net/bugs/1068158 If no issues are reported, I plan on releasing the packages as security updates in a couple of weeks. Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Mysql service does not restart after unattended upgrade on Hardy
On Fri, 2012-04-27 at 12:45 +0200, Lorenzo Salvadorini wrote: > Hi all, > we are experiencing this issue on many of our hardy hosts with > unattended upgrades enabled. > After upgrade from 5.0.51 to version 5.0.95 or from 5.0.95 to 5.0.96 > the upgrade fails and the mysql service does not restarts correctly. > With a manual restart the mysql service come up without any apparent > problem but the version is still the old one. The day after, we have > done the upgrade manually without any problem. We experienced this > problem on different platform and setup: > - on EC2 hosts and on physical hosts on common HP DL360 G6/G7 hardware. > - on mysql clustered with DRBD and standalone hosts > > I'm trying to understand what could be causing this behaviour reading > changelog or unattended upgrade logs/mail but I've not found anything > until now, is this happened to someone else? > It may be this bug: https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/988325 I'll look into it before the next security update. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: MySQL security updates
Hi, I have pushed updated MySQL 5.0.96 packages for Ubuntu 8.04 LTS, and updated MySQL 5.1.62 packages for Ubuntu 10.04 LTS, Ubuntu 11.04 and Ubuntu 11.10 into the -proposed pocket. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. The packages fix the following security issues: 5.1.62: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-62.html yaSSL was upgraded from version 1.7.2 to 2.2.0. Security Fix: Bug #13510739 and Bug #63775 were fixed. 5.0.96: http://dev.mysql.com/doc/refman/5.0/en/news-5-0-96.html yaSSL was upgraded from version 1.7.2 to 2.2.0. Please report any issues in the tracking bug: https://launchpad.net/bugs/965523 If no issues are reported, I plan on releasing the packages as security updates in a couple of weeks. Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Replacing setuid with file capabilities
On Thu, 2012-03-29 at 09:53 -0700, Clint Byrum wrote: > Excerpts from Serge Hallyn's message of Thu Mar 29 09:01:42 -0700 2012: > > Quoting Andrea Corbellini (corbellini.and...@gmail.com): > > > Hello, > > > > > > As many of you already know, there are some setuid executables in Ubuntu > > > that perform very specific tasks and do not need many special privileges > > > (ping and traceroute are just two examples). My proposal is to remove > > > their setuid flag and set the file capabilities they need through > > > setcap(8). This will indeed reduce the risk of privilege escalation. > > > > > > I think this is the right time to start discussing about this feature > > > because 12.10 is four releases away from the next LTS and the risk of > > > committing serious mistakes is lower. > > > > > > So, what do you think? Is it something that we could do for the > > > Q-series? > > > > One of the things which always blocked this in the past has been > > support for non-xattr filesystems, in particular NFS. Perhaps > > it's something postinst can tweak based on fs support? > > > > Couldn't hurt to have another session on this at next UDS. > > > > Wouldn't it be simpler to just have apparmor confine these binaries > to their intended setuid-needing capabilities? > Please read these first: http://permalink.gmane.org/gmane.comp.security.oss.general/3719 http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 I'm not convinced we won't be introducing all new vulnerabilities by trying to remove the setuid flag. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Call for testing: MySQL security updates
Hi, Since Oracle no longer publishes detailed information about security vulnerabilities that are being fixed in MySQL, and their bug tracker is no longer public, Ubuntu must now track upstream MySQL releases as security updates. MySQL 5.0.95 fixes the following CVEs: CVE-2012-0075, CVE-2012-0087, CVE-2012-0101, CVE-2012-0102, CVE-2012-0114, CVE-2012-0484, CVE-2012-0490. MySQL 5.1.61 fixes the following CVEs: CVE-2011-2262, CVE-2012-0075, CVE-2012-0112, CVE-2012-0113, CVE-2012-0114, CVE-2012-0115, CVE-2012-0116, CVE-2012-0117, CVE-2012-0118, CVE-2012-0119, CVE-2012-0120, CVE-2012-0484, CVE-2012-0485, CVE-2012-0486, CVE-2012-0487, CVE-2012-0488, CVE-2012-0489, CVE-2012-0490, CVE-2012-0491, CVE-2012-0492, CVE-2012-0493, CVE-2012-0494, CVE-2012-0495, CVE-2012-0496. For more information about the CVEs listed, please consult the January 2012 Oracle Critical Patch Update Advisory: http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html Today, I have pushed updated MySQL 5.0.95 packages for Ubuntu 8.04 LTS, and updated MySQL 5.1.61 packages for Ubuntu 10.04 LTS, Ubuntu 10.10, Ubuntu 11.04 and Ubuntu 11.10 into the -proposed pocket. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Please report any issues in the tracking bug: https://launchpad.net/bugs/937869 If no issues are reported, I plan on releasing the packages as security updates in a couple of weeks. Thanks, Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
On Thu, 2012-02-16 at 15:40 -0500, Barry Warsaw wrote: > The real question as to the future of c-j is whether it's even the right > approach to cleaning up your system. If so, then maybe a bit of engineering > to clean it up, better separate the backend from the dbus, ui, and cli > interfaces, and package it in a better way would be worth it. Ideally, something like this should be hooked up to apt, with an appropriate config option somewhere among the unattended upgrades or autoremove settings. Do we keep a successful boot flag for each kernel somewhere? It would be nice if the tool kept the currently running kernel, and the 3-5 previous kernels that have successfully booted. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: MySQL's future in Debian and Ubuntu
On Mon, 2012-02-13 at 10:11 -0600, Robbie Williamson wrote: > On 02/13/2012 01:20 AM, Eddie Bachle wrote: > > I would like to say we would still switch, or still heavily consider it > > for the grains that could be made by using Ubuntu, however > > realistically, the lack of native MySQL in any OS would be a huge mark > > against it. > > FTR, we would not *drop* MySQL support. Worst case scenario, we'd place > them in partner, much like we did with sun-java. The change would be > that our default/recommended DB would be MariaDB. > > > Also that being said, if the technical concerns are > > answered adequately for a vast majority of applications and hardware/OS > > setups, then I would be totally behind switching to a more open source > > friendly and compatible database software as there would be little love > > lost between me and MySQL. > > One thing to note, the primary motivator for this proposal isn't about > moving to a more "open source friendly" application. We have genuine > security concerns/issues with how MySQL handles and publishes their > security updates. We can't simply update supported prior Ubuntu > releases to newer MySQL versions, so we have to backport patches. Their > lack of information and access to the bugs addressed makes it *very* > time consuming and difficult for our security and SRU teams to do this. > If we can resolve these issues, then MySQL's future in main looks much > brighter. We are unable to determine what the recent MySQL security fixes are due to lack of details, and unclear commit messages. The only thing we can do to keep our users secure right now is to push MySQL 5.5.20 and 5.1.61 to our stable releases, which is less than ideal for various reasons. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: MySQL's future in Debian and Ubuntu
On Mon, 2012-02-13 at 02:20 -0500, Eddie Bachle wrote: > In general, I am generally an simply an observer on most of these > mailing lists, however my concerns with a switch are far less > technical and far more practical. I work currently for a college in > Michigan which utilizes almost solely Windows servers simply because > it is what the IT staff here knows. As a student here, I was brought > in to assist with the web server administration, and as time went by > because I have a degree of Linux knowledge, I was given permission to > put together a Ubuntu LAMP server to serve a couple of interested > parties on campus who wanted simply to demo several small scale web > apps that were Linux exclusive. This server would serve as an > exception to the general rule of our server architecture. However as > time has went by and my knowledge looks more like it will be a fixture > here after graduation, along with the simple instability of PHP and > Apache on the Windows platform, my boss is giving far more > consideration to moving to Linux. > > > As Linux gains more public recognition, more and more Windows-only > organizations will consider using it as an alternative, especially for > their web servers. This is especially true because of the fact that > each of the necessarily main components of a web server exist in Linux > in the same form as the do on Windows and often run much better. > Then, the only piece one would need to learn would be the new > operating system, not the database, HTTP server, or PHP scripting > language software. However, this is going to be a more difficult > proposition if the aforementioned advantage is somewhat eliminated. > Were I to have to tell my boss that we could switch to Ubuntu but it > would mean that would need to use a "MySQL compatible" database if we > want to use the native database (which we likely would because it's > tested to be stable and it is supported by the developers), then she > would be much more hesitant. If you prefer MySQL, you'll still be able to manually install it MySQL on Ubuntu and Debian, much like you manually install it on Windows. > > > There simply is a much greater sense of trepidation for those who are > not significantly Linux savvy if there exists a possibility that they > would have to make something work in an unfamiliar environment, > especially if it were to happen unexpectedly. If we ported our www > website server over to Ubuntu and then 6 months down the road we were > to upgrade our Joomla version and there became an issue with MariaDB > because it lacks some MySQL feature that it needs, or even that Joomla > would fail to recognize Maria as being equivalent to MySQL at some > point, then that would be a huge detraction against switching. I predict it will be the opposite. Once distros and people start switching to MariaDB, other projects will be testing on MariaDB by default, and compatibility with MySQL will then become problematic. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: MySQL's future in Debian and Ubuntu
On Sat, 2012-02-11 at 20:47 -0200, Fabio T. Leitao wrote: > I have already moved some of my servers to mariadb, with minor to none > downtime during the process, but I have also kept some of them stuck > with mysql just because of the "official" support (well, it is the > elected one in main repository after all) Out of curiosity, what version of MySQL did you migrate to what version of MariaDB? Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: MySQL's future in Debian and Ubuntu
On Tue, 2012-02-07 at 01:50 -0800, Clint Byrum wrote: > I'm writing to the greater Debian and Ubuntu community to ask for your > thoughts on a proposal to drop MySQL in favor of MariaDB. Its clear to > me that Oracle is not going to do work in the open, and this will become > a huge support burden for Linux distributions. The recent CVE's had to > be hunted down and investigated at great difficulty to several people, > since the KB articles referenced and the internal Oracle bug numbers > referenced were not available. > > This will only get harder as the community bug tracker gets further out > of sync with the private one. As a member of the security team, I think Oracle's move to a private bug tracker and not publishing details on the security issues is a disaster for Linux distributions attempting to maintain MySQL. I would support moving to a project that still does development in the open and is not actively trying to hide details of security issues. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Announcement: AppArmor profiles repository
We now have an official repository of in development AppArmor profiles: https://launchpad.net/apparmor-profiles This repository is where collaborative development of profiles can take place. Profiles in the development repository are in various states of completeness and once a profile reaches maturity, it is removed from the repository and placed into the application's package in the archive. Information on using the repository is available in the AppArmor wiki here: http://wiki.apparmor.net/index.php/Profiles Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ signature.asc Description: This is a digitally signed message part -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: No cron restart after pam upgrade?
On Tue, 2011-05-31 at 08:48 +0100, Darren Worrall wrote: > We've had his on our 10.04 boxes overnight. Is there a bug report filed? https://bugs.launchpad.net/ubuntu/+source/pam/+bug/790538 Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wed, 2011-03-30 at 11:00 -0400, Etienne Goyer wrote: > On 11-03-30 10:40 AM, Chuck Short wrote: > > I do not have the statistics in front of me, but I believe most of > > users are using LTS releases of Ubuntu. The policy of cherrypicking > > fixes from the development releases does not scale in my opinon. We > > should offer PPAs for users who want to use a new version of for > > example Apache. Or go through the list of packages we support and see > > if we can get it to qualify as a micro release update. > > Agreed. Some mechanism to "modularize" the distribution is in order. > From an end-user perspective, it does no make any sense that you need to > upgrade the OS to run a new version of Apache. I understand why we are > doing this from the distribution perspective, and I know a lot of people > are very attached to the way things are being done now, but it really > baffles people coming to Ubuntu from other platforms at time. On the other hand, it doesn't make sense to break everyone's servers every month when we update the apache or php version and the config files/features/ABI change and their applications stop working. This is the type of thing that enterprises dread...and is why IE6 took so long to die... Most people in enterprise scenarios that I've seen who use stuff like Apache on other platforms tend to install the latest version once, and stick with that version for the life of the server once it goes into production...foregoing any security updates. In fact, the constant update of Apache to remain secure on Windows is one of the reasons I've seen listed in security audits that recommend either migrating to IIS, which remains at the same version throughout the life of the OS, but gets constant security updates, or switching to Linux to benefit from stable release security updates. Apache may be a bad example here for the type of application that should get updated instead of fixed, as it is not something that is stand-alone enough and updating it would have a great impact on Ubuntu use in enterprise environments. Besides backports, there is also a process to obtain micro-release exceptions. Unfortunately, upstream projects who don't change ABI/config files/features with new versions are the exception and the massive QA effort to test upgrading them in stable releases would be orders of magnitude bigger than backporting a patch to fix a specific issue with a specific test case. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSL by default for all packaged web apps?
On Wed, 2011-03-02 at 17:05 +0200, Clint Byrum wrote: > On Wed, 2011-03-02 at 08:45 -0500, Marc Deslauriers wrote: > > On Wed, 2011-03-02 at 08:23 +, Hakan Koseoglu wrote: > > > Forcing a naive system administrator to think about SSL & certificates > > > is at least something useful. Of course there should be abilities to > > > opt-out where SSL is not required. On the other hand, it's like saying > > > "on secured networks SSH is not required, telnet is all you need" and > > > I'm sure all of us would look at that sentence and mutter "insanity!". > > > > Please don't compare using password-protected SSH with using self-signed > > certificates. Using passwords instead of certificates with SSH has no > > impact on it's effectiveness against MITM attacks. Of course it's better > > then Telnet. > > > > It is trivial to MITM self-signed certs, thereby countering any security > > advantage by adding SSL. Of course, I assume that people who are > > clicking Accept in their browser aren't validating the SSL cert > > fingerprint, as technical SSH users are instructed to do. > > > > I think you're trivializing a decent analogy, though I agree its not > entirely the same. However, SSH carries the same fingerprint > verification problem that makes MITM just as simple on the first > connection. Most browser users will save the certificate and be warned > if it changes, just like the SSH user will be warned. > > The main difference is that ssh would generally be used by a more > conscientious user than a browser user. > I totally agree. If web ssl self-signed certs were only for sysadmins who would know to validate the fingerprint and suspect something is wrong when they get a new browser warning, there would be a big advantage to turning it on. Unfortunately, that's not the case, and it's why you can't deploy self-signed certs to end users and expect any level of security. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSL by default for all packaged web apps?
On Wed, 2011-03-02 at 08:23 +, Hakan Koseoglu wrote: > Hi Clint, > > On 22 February 2011 22:56, Clint Byrum wrote: > > This bug was opened recently: > > > > https://bugs.launchpad.net/bugs/695857 > > > > It suggests that packages should configure themselves to require SSL by > > default. > > > > I think this is actually a good idea, and I am wondering how this would > > be received by the greater community. > +1. It's a starting point. > > A good sample is SSH. You are not supposed to use password > authenticated based SSH and only use passphrase protected distributed > keys but hey, it's way better than Telnet in all cases! > > Forcing a naive system administrator to think about SSL & certificates > is at least something useful. Of course there should be abilities to > opt-out where SSL is not required. On the other hand, it's like saying > "on secured networks SSH is not required, telnet is all you need" and > I'm sure all of us would look at that sentence and mutter "insanity!". Please don't compare using password-protected SSH with using self-signed certificates. Using passwords instead of certificates with SSH has no impact on it's effectiveness against MITM attacks. Of course it's better then Telnet. It is trivial to MITM self-signed certs, thereby countering any security advantage by adding SSL. Of course, I assume that people who are clicking Accept in their browser aren't validating the SSL cert fingerprint, as technical SSH users are instructed to do. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSL by default for all packaged web apps?
On Wed, 2011-03-02 at 00:38 -0500, Etienne Goyer wrote: > Re-reading my email, I think I got a bit too snarky toward the end. > While I think my arguments are sound, the discussion does not have to be > confrontational. My apologies to Marc and the list for the tone I used > earlier. No apologies necessary Etienne. I don't think you can have a snarkier tone than I do on mailing lists sometimes. :) Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSL by default for all packaged web apps?
On Tue, 2011-03-01 at 21:01 -0500, Etienne Goyer wrote: > >> 1. Encrypting communication between the client and the server (notably > >> to protect the credential exchange from eavesdropping). > >> > >> 2. Preventing MitM by authenticating the server. > >> > >> > >> Using SSL with self-signed certificate doesn't address 2., but it does > >> address 1. From my perspective, it's an incremental improvement over > >> plain-text HTTP. So, why not? > > > > I'm not quite sure under which circumstance 1 would be a problem but 2 > > would not. When you're on a trusted network? If you're on a trusted > > network, you probably don't need SSL in the first place. > > There's no such thing as a trusted network. I am just saying that > encrypting traffic is an incremental improvement over plain-text HTTP. Given that it's a _lot_ easier to MITM a switched network than it is to eavesdrop on one, I don't think this would be much of an improvement. > > > The problem here is that turning it on by default will instill a false > > sense of security into people's minds. You are telling them that it's > > acceptable to bypass the important warnings and to click the "OK" button > > in Firefox when they connect the first time. You are showing them the > > lock icon in Firefox indicating to them that they're on a secure > > connection, when in fact, that's not the case... > > Yet, most internal web service (those that aren't public-facing) require > the end-user to dismiss a self-signed certificate already. That's what > I see out there. Turning SSL on by default would not be a regression, > it would be an incremental improvement over plain-text HTTP. This is incredibly wrong and no organisation who's had a security audit would be able to continue doing so, unless what's being protected is of no value, including the passwords that are being used. > >> I have had that argument with a few people over the years. Fact is, at > >> least for non publicly facing web services, most people will continue to > >> use self-signed certificates for the simple reason that getting a > >> "valid" certificate (or setting up your own CA) is a huge hassle, and > >> not even always possible. > > > > They are trading off security to save $50 and 30 minutes of work. > > Unless, of course, you are getting every single user to manually > > validate the fingerprint every time they click that Accept button. > > And this is the crux of the matter. I have had this argument served > recently by obnoxious developers of an application that would not run > without a valid SSL certificate, and it was of no help to me. On > internal network, organisation of all size often use non-registred > domain name. You cannot get a valid SSL certification signed by a CA > for a .silly domain, however hard you try. Plus, it's often much more > involved that 50$ and 30 minutes. Sometime, it requires you seek > approval from procurement, IT security or net ops department to buy a > certificate in the name of your org. There _are_ valid use-cases for self-signed certificates. I don't think _preventing_ the use of self-signed certs to be the right thing to do. Using an unregistered domain name for an internal network is bad network design, and causes a lot of problems, including an SSL cert problem. Inventing any random TLD seems to have had a splurge in popularity when Active Directory showed up. I agree, purchasing a certificate can be more complex than what I describedbut I don't think self-signed certs are any kind of valid replacement. > > > >> I would even go as far as arguing that trying to discourage people from > >> using self-signed certificate through systemic measure is a waste of > >> time, because most people just do not understand the implication. > >> Putting the cart before the horses and stuff. > > > > Setting up an insecure SSL connection by default, and giving them the > > impression of being encrypted properly is security theatre. This isn't > > something we should be recommending, or doing by default. If someone > > decides that self-signed certificates are "good enough" for them, they > > should set it up themselves and face the consequences. > > And that is what most people are currently doing, in fact. They would > be none the worst if we enabled SSL by default. Just because they are doing something terribly insecure already doesn't mean we should be doing it by default. Self-signed certs don't improve security over clear text in any significant way (unless used by technical people who check fingerprints, etc.) > > But, in the end, I do not care much and I am not going to argue any more > in favor of the proposal. It's just an incremental usability > improvement, like ssh-installed-by-default would have been. We could > nitpick all night long about the fine point of security vs usability, > but it's not very productive. I do think that we need something easier to set up SSL though, and that may be what we should put
Re: SSL by default for all packaged web apps?
On Tue, 2011-03-01 at 18:04 -0500, Etienne Goyer wrote: > > We should not turn on SSL by default with self-signed certificates. That > > is insecure and is not a configuration that should be encouraged. > > There is two things there: > > 1. Encrypting communication between the client and the server (notably > to protect the credential exchange from eavesdropping). > > 2. Preventing MitM by authenticating the server. > > > Using SSL with self-signed certificate doesn't address 2., but it does > address 1. From my perspective, it's an incremental improvement over > plain-text HTTP. So, why not? I'm not quite sure under which circumstance 1 would be a problem but 2 would not. When you're on a trusted network? If you're on a trusted network, you probably don't need SSL in the first place. The problem here is that turning it on by default will instill a false sense of security into people's minds. You are telling them that it's acceptable to bypass the important warnings and to click the "OK" button in Firefox when they connect the first time. You are showing them the lock icon in Firefox indicating to them that they're on a secure connection, when in fact, that's not the case... > > I have had that argument with a few people over the years. Fact is, at > least for non publicly facing web services, most people will continue to > use self-signed certificates for the simple reason that getting a > "valid" certificate (or setting up your own CA) is a huge hassle, and > not even always possible. They are trading off security to save $50 and 30 minutes of work. Unless, of course, you are getting every single user to manually validate the fingerprint every time they click that Accept button. > > I would even go as far as arguing that trying to discourage people from > using self-signed certificate through systemic measure is a waste of > time, because most people just do not understand the implication. > Putting the cart before the horses and stuff. Setting up an insecure SSL connection by default, and giving them the impression of being encrypted properly is security theatre. This isn't something we should be recommending, or doing by default. If someone decides that self-signed certificates are "good enough" for them, they should set it up themselves and face the consequences. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSL by default for all packaged web apps?
On Tue, 2011-02-22 at 14:56 -0800, Clint Byrum wrote: > This bug was opened recently: > > https://bugs.launchpad.net/bugs/695857 > > It suggests that packages should configure themselves to require SSL by > default. > > I think this is actually a good idea, and I am wondering how this would > be received by the greater community. > > I am marking the bug as "Opinion" and I'd like to get the opinions of > the server community as a whole on the issue. If enough people think its > a good idea we can open a blueprint for a future UDS. We should not turn on SSL by default with self-signed certificates. That is insecure and is not a configuration that should be encouraged. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSH and the Ubuntu Server
On Fri, 2010-11-19 at 13:06 -0500, Scott Kitterman wrote: > On Friday, November 19, 2010 12:40:17 pm Marc Deslauriers wrote: > > On Fri, 2010-11-19 at 17:05 +0100, Soren Hansen wrote: > > > On 18-11-2010 16:49, Marc Deslauriers wrote: > > > > I want the person installing the server to actually make the choice > > > > to install ssh in order to realize that doing so may have > > > > consequences. ie: "Oh wait, If I install ssh now, I should unplug the > > > > server from the network and configure ssh properly before hooking it > > > > back up..." > > > > > > What does "configure ssh properly" usually entail? Are these some > > > defaults we can change or offer as follow-on questions if people answer > > > "Yes" to this dialog? (Yes, I fully realise that will very likely result > > > in a net loss in usability on account of more questions asked, just > > > trying to get something constructive out of this thread) > > > > I think this highly depends on the environment the server is set up in, > > and is beyond the scope of the installer, but typically one or more of > > the following: > > > > - Limit ssh to a specific network interface > > - Disable password authentication and copy over keys > > - Configure AllowUsers and/or AllowGroups > > - Disable DebianBanner > > - Configure a firewall to limit connections from specific IPs and enable > > rate limiting > > - Configure tcpwrappers to limit connections from specific IPs > > - Install fail2ban or denyhosts > > - Add server to corporate IPS ssh-monitored host group > > - etc. > > > > SSH password brute-forcing has been on the SANS Top 20 vulnerability > > list for the past 10 years or so. > > Where do we document this for our users so they can take appropriate actions? Same place we document everything else: in our wiki and on help.ubuntu.com. https://help.ubuntu.com/community/SSH https://help.ubuntu.com/community/SSH/OpenSSH/Configuring Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSH and the Ubuntu Server
On Fri, 2010-11-19 at 17:05 +0100, Soren Hansen wrote: > On 18-11-2010 16:49, Marc Deslauriers wrote: > > I want the person installing the server to actually make the choice > > to install ssh in order to realize that doing so may have > > consequences. ie: "Oh wait, If I install ssh now, I should unplug the > > server from the network and configure ssh properly before hooking it > > back up..." > > What does "configure ssh properly" usually entail? Are these some > defaults we can change or offer as follow-on questions if people answer > "Yes" to this dialog? (Yes, I fully realise that will very likely result > in a net loss in usability on account of more questions asked, just > trying to get something constructive out of this thread) > I think this highly depends on the environment the server is set up in, and is beyond the scope of the installer, but typically one or more of the following: - Limit ssh to a specific network interface - Disable password authentication and copy over keys - Configure AllowUsers and/or AllowGroups - Disable DebianBanner - Configure a firewall to limit connections from specific IPs and enable rate limiting - Configure tcpwrappers to limit connections from specific IPs - Install fail2ban or denyhosts - Add server to corporate IPS ssh-monitored host group - etc. SSH password brute-forcing has been on the SANS Top 20 vulnerability list for the past 10 years or so. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: SSH and the Ubuntu Server
Hello, On Thu, 2010-11-18 at 08:00 -0600, Dustin Kirkland wrote: > > -- > > | If you need a secure connection to this > > | server remotely, you may wish to install > > | the openssh-server package. Note that > > | this service will open TCP port 22 on > > | your system, and you should use a very > > | strong password. > > | > > | Do you want to install the SSH service? > > | > > |[[YES]][no] > > -- > > > > Rest assured that the exact text will be word-smithed by an > > appropriate committee to hash out an optimum verbiage. I think this screen is a good idea if in fact tasksel is moved to after the first boot. We would need to change the wording though as using ssh with password authentication is insecure and should not be something we recommend. A lot of users who come to #ubuntu-hardened trying to figure out why their server was compromised end up discovering that ssh password brute-forcing was the cause. > > > > This proposal requests that: > > 1) a new prompt be added to the Ubuntu Server installer > > 2) this prompt be dedicated to the boolean installation, or > > non-installation, of the SSH service, as an essential facet of a > > typical server > > 3) the cursor highlights the affirmative (yes, please install SSH), > > but awaits the user's conscious decision This is where I disagree. Dangerous actions should not be the default choice. I've seen numerous corporate environments where the default/generic account used during server installation was still enabled when the server went into production. I want the person installing the server to actually make the choice to install ssh in order to realize that doing so may have consequences. ie: "Oh wait, If I install ssh now, I should unplug the server from the network and configure ssh properly before hooking it back up..." Making the cursor default to "yes" means people who install the server and don't know the impact of answering yes will get something dangerous installed that they weren't counting on. > > > > These key points map to the following considerations: > > 1) the current option to install SSH on Ubuntu servers is buried in > > the tasksel menu > >- SSH is more fundamental to a server than the higher level > > profile selections for: > > DNS Server, Mail Server, LAMP Stack, Virtualization Host, etc. > > 2) users of the installation ISO will have the option to not install > > SSH, as they so desire > >- it is quite well understood that some users may not want SSH > > installed on their server Corporate environments don't typically allow ssh access to servers from the main network for security and conformance reasons. Remote management cards and IP KVMs are often used from an isolated administrative network, or SSH is configured to listen only to a specific network interface. Contrary to what some people have suggested, pre-seeding isn't used in a lot of these cases. This is one of the reasons I like having SSH as a choice during install, and not simply installed by default. > > 3) highlighting the "YES" option on this page is absolutely essential > > to addressing this usability issue > >- and that selection is easily overridden by hitting , > > or by experienced admins in preseed configurations SSH can just as easily be enabled by hitting also. > > > > Please consider that the very definition of a "server" implies that > > the system is running a "service". Moreover, our official Ubuntu > > Server images as published for the Amazon EC2 cloud are, in fact, > > running SSH by default listening on port 22 on the unrestricted > > Internet (the 'ubuntu' has no password), and the Ubuntu Enterprise > > Cloud installation by the very same ISO installs SSH on every every > > UEC system deployed. This is not unprecedented. As far as I recall, EC2 opens the ssh port from your ip address only, and authenticates using certificates and not passwords. Actually, now that you mention it, we should probably disable SSH password authentication by default in the EC2 images... As for UEC, I don't think that's a "default installation" as the person installing is selecting to install a bunch of software that opens a bunch of ports, including SSH. > > > > Having discussed the proposal with a subset of this audience (at UDS > > and in IRC), here are some known FAQs: > > > > Q: WTF?!? Ubuntu has no open ports by default! > > A: That depends on which "Ubuntu" you mean. Ubuntu-in-the-cloud runs > > SSH. Ubuntu-as-the-cloud runs SSH. Ubuntu desktops run avahi. Most > > importantly, this is not a "run by default" proposal. We have already > > compromised on that subject, culminating in this proposal, which is > > simply about providing Server users with an obvious way to install the > > typically essential SSH service. > > > > Q: Why not default the cursor on that question to "No", i
Re: double information in motd
Hi, On Wed, 2010-07-14 at 10:23 +0200, Alvin wrote: > If I log in remotely, some servers show double statistics for apt, like this: > > 0 packages can be updated. > 0 updates are security updates. > > 0 packages can be updated. > 0 updates are security updates. > > /var/run/motd contains the duplicate information. > /usr/lib/update-notifier/update-motd-updates-available contains the command > that produces this output (/usr/lib/update-notifier/apt-check --human- > readable) > > Any idea why this output appears twice? You probably installed lucid when it was in alpha/beta. Check to see if your /etc/motd.tail file is empty. If not, empty it. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: PHP 5.3 for Lucid
On Wed, 2010-02-10 at 07:51 +0900, Emmet Hikory wrote: > Kees Cook wrote: > > Mathias Gug wrote: > >> Right. There are a couple of php packages (drupal, joomla, etc...) > >> currently in Lucid that are not working with 5.3. These would have to > >> be ported to 5.3 before we release. > > > > Joomla isn't in Ubuntu, and drupal (universe) should not block php (main). > > I thought the fridge used drupal. While I generally agree that we > shouldn't block a transitoin based on one stubborn package, I'd hope > we'd be able to upgrade our shared infrastructure to the next LTS > without needing to deploy an entirely new platform. I agree entirely > about joomla, but someone ought port drupal prior to release if the > transition goes ahead. Drupal 6.14 and later should work okay with php 5.3. We currently have drupal 6.15 in lucid. There may be some modules that don't work properly, but we don't ship those. See: http://drupal.org/requirements http://drupal.org/node/360605 Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: RFC: Ipsec support in main
Hi, On Mon, 2010-01-04 at 17:01 -0500, Mathias Gug wrote: > On Mon, Jan 4, 2010 at 1:33 PM, Martin Pitt wrote: > > Hello Mathias, > > > > Mathias Gug [2010-01-04 12:23 -0500]: > >> If not the following packages could be demoted to universe: > >> * ipsec-tools (and racoon) given its vulnerability history > > > > Some years ago I actually used ipsec-tools (not racoon) to setup a VPN > > in our university, but nowadays I'm using openvpn; it's simpler to set > > up, and is supported with more devices (mobile phones, routers, etc.) > > Agreed. It seems that there are at least two solutions to implement a > VPN in main: OpenVPN and IPSEC. I wonder how popular are IPSEC-based > VPNs nowadays? IPSEC-based VPNs are used in all enterprise scenarios. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
