Re: apport permission error
On Thu, Feb 20, 2020 at 03:45:39AM +, Seth Arnold wrote: > I'm worried that turning this flag on for the first time in an LTS release > may be breaking too many expectations. > > Adapting applications may be too much effort; because I don't know what > exactly apport is doing here it is hard to estimate how much effort it > will take to adapt it. Possibly the user-launched apport instances need > to create their own directory on launch. Possibly apport needs a > more invasive redesign. > [...] > Source code searching is not practical. The combination of working > with files in a world-writable sticky directory and not already using > O_EXCL with O_CREAT is not feasible to search for. FWIW, I think that the scope of the change is small enough (only in world-writable stick directories) and dramatic enough (usually total failure), that the risk is worth the benefit. Excepting the very few special directories (like /var/crash, where the software using them is likely enumerable), I would also argue that breaking stuff in "standard" temp directories (like /tmp) that isn't using O_EXCL is actually _desirable_, given that it is expressly risky to operate in that condition. And, I would suggest that doing this in an LTS is the right thing to do, otherwise you wait 2 years before gaining this defense that would be actively _disabled_ compared to all other distros with a modern version of systemd. And if this is the first noticed problem, that seems to be a reasonably good indication of how rare the case is of it creating "real" problems. -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Thu, Aug 02, 2018 at 11:21:28AM -0700, Steve Langasek wrote: > On Thu, Aug 02, 2018 at 09:41:11AM -0700, Kees Cook wrote: > > On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote: > > > - Where root filesystems are distributed as tarballs, they are not > > >currently created with --xattrs; this will need to be changed. > > > What about initramfs? CPIO doesn't support xattr: > > https://lkml.kernel.org/r/1516850875-25066-1-git-send-email-takon...@cisco.com > > This seems like it would only be relevant for IMA, not for fscaps (since > everything in the initramfs runs as uid 0). Is that fair to say? Okay, that's true -- I can't think of anything that expects to run without privileges during initramfs. > Since lack of xattrs in cpio is a known limitation, and files don't end up > in an initrd without specific action by a package (which would be the same > in Debian and Ubuntu), I think this is severable from the question of > requiring xattr-preserving handling of an Ubuntu root filesystem. Agreed. > > > - Users who are unpacking root tarballs need to take care to pass > > >--xattrs-include=* to tar. > > > - Users who are backing up or streaming Ubuntu root filesystems with tar > > > or > > >rsync will need to take care to pass non-default xattr-preserving > > > options > > >(tar --xattrs; rsync -X). > > > How about making these default-enabled? Hoping people will remember seems > > fragile. > > I think that's appropriate to pursue with the upstream, but that we should > still socialize the recommendation to use the options explicitly for > portability. While I agree about pursuing it with upstreams, I don't agree about just leaving this to documentation/luck. The problem is distro-specific (i.e. the packages built and the root filesystem being used), so I think it's fair to make the tools involved in that distro DTRT by default when it comes to xattrs. (Everything else is expected to work together correctly, why not the tools too?) -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote: > - Where root filesystems are distributed as tarballs, they are not >currently created with --xattrs; this will need to be changed. What about initramfs? CPIO doesn't support xattr: https://lkml.kernel.org/r/1516850875-25066-1-git-send-email-takon...@cisco.com > - Users who are unpacking root tarballs need to take care to pass >--xattrs-include=* to tar. > - Users who are backing up or streaming Ubuntu root filesystems with tar or >rsync will need to take care to pass non-default xattr-preserving options >(tar --xattrs; rsync -X). How about making these default-enabled? Hoping people will remember seems fragile. > - GNU tar's xattrs format incompatible with other unpack implementations >(e.g. libarchive)[1]. Anyone using another unpacker will necessarily >end up without fscaps. Seems like these unpackers should be fixed? -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
Hi Oliver, On Thu, Jun 27, 2013 at 08:41:51AM -0600, Oliver Ries wrote: > Our Display Server Mir has gone from a proof of concept, sufficient to > justify its announcement in March this year, to high quality, high > performance component that we think will deliver the fastest, cleanest > display experience for the Ubuntu platform. We are confident that all > desktop environments and derivatives will work well throughout the > transition, based on our ability to provide a full X compatibility layer. This is great! I'm really looking forward to having a viable windowing system that isn't hampered by X's limitations. Do you have some pointers to documentation on the security design work? This is, unsurprisingly for people that know me, of significant interest to me. Having a clear way to isolate windows and inputs has been, as I'm sure you know, a long-time need in X. And maybe we can get scan codes >255 now, too. :) > Here is the roadmap and milestones for the Ubuntu graphics stack transition > to Mir: > > Ubuntu 13.10: > XMir on Mir by default, with a fallback session to X where there is no Mir > driver support, supported for 9 months While I recognize this is a roadmap, this seems unrealistic to me. I feel there has been a long history of adopting things as default too early. With bugs like "vt switching doesn't work", and feature freeze in 2 months, I think it is way too early to declare something ready for default. Certainly ship it, make it available, but don't make it the default. Doing so would just make unwilling testers out Ubuntu users. Let people interested in the software test it, and once there is a trusted level of stability and features, make it the default. And to that end, do you have documented comparisons of performance between native X and XMir (especially for non-Unity stacks)? The video demo does appear to be measuring it, but I'd be curious to see the before/after results in some tabulated form. > Feel free to discuss any questions with the team directly here or on the > mir-devel list. > > Ubuntu will be the first Linux distribution to start replacing X as part of > their default configuration. We appreciate your support and patience in > that endeavor. Replacing X is no small task! Thanks for spearheading this; I really want the transition to be successful. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default layout of the GNOME Classic session
On Sun, Apr 22, 2012 at 05:20:14PM +0200, Jo-Erlend Schinstad wrote: > Den 22. april 2012 17:15, skrev Martin Pitt: > > I would actually prefer to do it the other way around: Drop indicators > > and other Ubuntu-isms and ship the (mostly) pristine GNOME upstream > > experience with gnome-panel. In earlier releases we had the > > "straciatella" session, but we don't have this any more. The session > > says "GNOME", and so should _be_ a GNOME session, not another Ubuntu > > session. > > Perhaps it might make more sense to change the label than to change the > software it describes? I've written about this before. I'd much rather > call it Ubuntu Classic. This is Ubuntu, after all. If I were a 10.04 > user and I couldn't use indicators anymore, I would certainly consider > that to be a regression. Right, I would prefer renaming it instead of removing functionality. The whole reason I want this "Ubuntu Classic" mode is to retain functionality. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.04 LTS: 64-bit desktop by default?
On Wed, Apr 18, 2012 at 08:13:15PM -0700, Steve Langasek wrote:
> On Wed, Apr 18, 2012 at 11:31:47AM +0200, Rolf Kutz wrote:
> > On 17/04/12 16:17 -0700, Steve Langasek wrote:
> > >Additionally, as mentioned in this thread, the message presented to users
> > >when they try to boot a 64-bit image on a 32-bit machine is jargon-y
> > >("kernel"; "x86_64"). A bug has been filed about this and should be fixed
> > >soon, but I don't think it makes sense for us to commit to 64-bit by
> > >default
> > >in the current state.
>
> > Maybe there could be a message on 32Bit Ubuntu
> > ınforming the user about the 64 Bit option, if it
> > finds a suitable system with enough RAM.
>
> That sounds like an interesting idea. We already have some tools along
> these lines, to warn about things like failing to use the CPU's NX flag (on
> servers) or notifying users of battery recalls (on laptops). Maybe this is
> something that could be integrated into the live environment for 12.10?
The NX flag warning was removed in favor of fixing it directly in the
kernel[1]. However, that code (cpu-checker) could easily be used again
for checking "lm" and RAM levels. It even already has the update-notifier
bits plumbed[2].
-Kees
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ae84739c27b6b3725993202fe02ff35ab86468e1
[2]
http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/files/head:/update-notifier/
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.04 LTS: 64-bit desktop by default?
On Tue, Apr 17, 2012 at 04:17:22PM -0700, Steve Langasek wrote:
> The key one is this: 25% of all (~16k) submissions to Ubuntu Friendly are
> from 32-bit machines.
Hrm. My sample[1] of x86 CPUs taken from Launchpad Bug reports in Nov 2009
is smaller (7264), but shows a change in adoption rate (4945 had "lm"
in /proc/cpuinfo), at 32% 32-bit. So 29 months later, 32-bitness has
fallen 7%. In 2021 we'll be 0% 32-bit! Well ahead of the 2038 bug! ;)
The problem, frankly, is this is all self-reporting, and doesn't have
anything to do with the target of "new installs".
> Now, this doesn't look at how the ratio is changing over time; but Ubuntu
> Friendly is itself still a fairly recent initiative, so I don't expect this
> to have changed much. Switching our default image to a version that just
> plain won't work on nearly a quarter of the machines users want to use it on
> strikes me as a non-starter. That's a much higher percentage than anyone
> was expecting based on the UDS discussion.
Upgrades will stay on whatever they had before. By definition then,
all data gathered about existing installs is out of date.
Regardless, going with the UF measurements, why are we penalizing 75% of
Ubuntu users? Their experience could be arguably better on 64-bit. It's
not like we're killing 32-bit. We've killed entire architectures when new
installs hit 5%. It doesn't seem like it makes sense to wait to change
the _default_. If things get much lower, people will just want to remove
the arch entirely. For an LTS, it seems all the more critical to produce
defaults that will make sense for 5 years. (Assuming the linear 0.24%
drop per month, at the end of 12.04's LTSness, 14% of the user base will
have 32-bit CPUs -- seems like it'd be way overdue to change the default
by then.)
> Additionally, as mentioned in this thread, the message presented to users
> when they try to boot a 64-bit image on a 32-bit machine is jargon-y
> ("kernel"; "x86_64"). A bug has been filed about this and should be fixed
> soon, but I don't think it makes sense for us to commit to 64-bit by default
> in the current state.
Yeah, fixing this would go a long way toward solving the educational
issues.
> So while amd64 is clearly the better option for 64-bit machines with more
> than 2GB of RAM, it looks like it would be premature to make this the
> default. Faced with a choice between a default that will be less efficient
> on higher-end machines, and a default that will fail to boot at all on a
> quarter of machines, I think we need to be conservative here and stay with
> 32-bit by default in 12.04. I will therefore not be asking the web team to
> point at the amd64 desktop image as the default.
How about changing the way the web presents the default, and move it
to 64-bit? For example...
Download Ubuntu 12.04 [64-bit] (not sure? Try [32-bit] instead)
> I'll work with the Ubuntu Friendly team to monitor changes in the adoption
> of 64-bit CPUs for future releases; and of course users who know amd64 is a
> good fit for them are encouraged to use it in 12.04 LTS as well, since both
> amd64 and i386 remain fully-supported options in this release.
It seems like I should start trying to deprecate 32-bit so changing the
default to 64-bit seems like a less radical idea. :)
-Kees
[1]
http://bazaar.launchpad.net/~cpu-checker-dev/cpu-checker/trunk/files/head:/test/
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.04 LTS: 64-bit desktop by default?
On Tue, Apr 17, 2012 at 11:08:41AM +0100, Colin Watson wrote: > On Tue, Apr 17, 2012 at 02:14:26AM +0200, Pavel Rojtberg wrote: > > I would not bet that 14.04 users necessarily will have to get 64bit. > > There is the recent x32-abi[1] development which kind of combines > > best of both worlds. > > Is it worth a UDS session on how we might make use of x32? Since the > patches aren't e.g. on glibc trunk yet, I don't think we can reasonably > make any concrete plans, but perhaps we should be thinking in advance > about issues such as partial architectures that x32 brings up. It's worth noting that running x32 requires a 64-bit kernel. Moving to x32 would be as big a deal (if not more) as moving to x86_64 from ia32. And personally, I think just moving to x86_64 is the better goal. :) -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.04 LTS: 64-bit desktop by default?
On Sun, Apr 15, 2012 at 11:03:14PM -0700, Steve Langasek wrote: > Are there problems that we've overlooked with regards to shipping 64-bit by > default on the desktop, or is it reasonable to make this switch for 12.04 > LTS? Is there 32-bit binary software that you know about which is not yet > supported on amd64 via multiarch, and ought to be before we consider making > 64-bit the default? > > Note that we're talking about three changes here: > > - Changing the default download link on ubuntu.com to point to 64-bit >desktop images > - Changing the pressed CDs distributed by Canonical to be 64-bit instead of >32-bit > - Changing the architecture used for preformatted USB disks sold in the >Canonical shop > > In general, if people can think of reasons not to switch to 64-bit for one > of these, those arguments would apply to the other; so if we think we're > ready for a switch, that switch should be applied across the board. I'm strongly in favor of making 64-bit the default. IMHO, most of the weird stuff I use (e.g. dosemu) actually runs better in 64-bit. Anything grossly weird (e.g. binary-only 32-bit MPlayer codecs) runs fine in a 32-bit chroot, and those kinds of things aren't even in the archive. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.04 LTS: 64-bit desktop by default?
On Mon, Apr 16, 2012 at 02:36:32PM -0700, Scott Ritchie wrote: > On 4/16/12 9:25 AM, Steve Langasek wrote: > >On Mon, Apr 16, 2012 at 11:09:19AM -0400, Michael Terry wrote: > >>On 16/04/12 02:03, Steve Langasek wrote: > >>>And regardless of which we decide to use as the default, both of amd64 and > >>>i386 will continue to be supported architectures for the length of 12.04 > >>>LTS > >>>and will remain available for download. > > > >>There seems to be an unstated assumption that the default > >>recommended architecture needs to stay the same throughout the > >>lifecycle of 12.04 LTS. Is that true? > > > >I don't see us making such a change for a point release. First, we don't > >typically get CDs pressed of point releases; second, there is going to be > >some confusion on the part of users about this change, and I think we can > >better mitigate that if changing it as part of .0 instead of as a point > >release. > > > >>If we end up deciding to stick with i386 for now to better support > >>common hardware, this question will still be re-evaluated for a > >>future release. And when it changes, we could go back and change > >>the default download link and what is installed on the store USB > >>sticks for 12.04 LTS. > > > >We could, but I'm pretty sure it's not worth it at that point. > > > > Relatedly, I'm worried about what happens when these 12.04 users > upgrade to 14.04. It would be really unfortunate to have them still > on 32 bit by that point. I think that's entirely out of scope. This was a question about the default arch for downloads and CD pressing. Upgrades will continue on the arch they had, which is totally fine since it remains a very support arch. :) > Unless, of course, we have ambitions of supporting automatic > cross-architecture upgrades by then. I'm sure people will attempt this, but doing this automatically is a way off. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Proposal to disable Wubi Installs from 12.04 (but maintain the separate .exe)
On Tue, Mar 20, 2012 at 09:37:06AM -0700, Steve Langasek wrote: > 3. We disable the ability to do a wubi installation from the Ubuntu 12.04 > ISOs. (wubi will remain on the images for the purpose of providing Windows > users some feedback and functionality if they put a Ubuntu CD into a > running Windows computer, but won't offer to install). > > At this time, we don't expect to be able to reclaim any space on the ISO > with this change. In the future we may consider splitting the autorun menu > out of wubi.exe to save some space (this is how it was structured > originally), but it's very late in the cycle to attempt such a refactoring > for 12.04. It's safer to simply disable the "install" option when run from > the CD. Oh, whoops. I re-read Rick's email a few times and continued to miss that. What kind of feedback is shown with this change? Is it actually useful (i.e. not just "install" greyed out)? -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Proposal to disable Wubi Installs from 12.04 (but maintain the separate .exe)
Hi, On Tue, Mar 20, 2012 at 05:15:02PM +0100, Rick Spencer wrote: > Separating the wubi.exe experience from the ISOs will give us the following > important benefits: > > 1. We will be able to do maintenance and enhancements to wubi outside of > the Ubuntu development cycle. > 2. Significant reduciton of QA work for an already over-streched QA team. > 3. Better overall 12.04 quality, and less stress at release time. > 4. We won't get stuck with a poor (or worse) user experience on the CD > since is a good chance that wubi will not work properly with Windows 8. > > I am proposing these changes to the plan because: > > 1. The key use case for wubi is being able to download and run the > installer on Windows, not installing from the ISO. > 2. Wubi is difficult to test, so has been difficult to assure that it will > meet the quality standards we have set for 12.04. > 3. There are no developers treating wubi as their top priorities. This > combined with the QA difficulties has historically caused late breaking > changes that add stress at release time and frequentily invalidate already > executed ISO testing. > 4. Most significantly, Windows is changing it's boot system with Windows > 8, and it's not clear how wubi will work with Windows 8, if at all. How much space is reclaimed on the ISO with the removal of Wubi? -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
Hi Gary, On Thu, Mar 01, 2012 at 05:08:36PM -0500, Gary Poster wrote: > aufs was reliable for us on Oneiric when creating ephemeral lxc > instances based on an underlying template. The most recent > overlayfs issue that we discovered is today's > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 > > The summary is that, within an overlayfs, this fails: > > gary@garubtosh:~/tmp$ touch 3 > gary@garubtosh:~/tmp$ chmod 0444 3 > gary@garubtosh:~/tmp$ ln 3 4 > ln: failed to create hard link `4' => `3': Operation not permitted > > That error makes xvfb unable to start, in this particular case. > > I'd feel a *lot* more comfortable if aufs were still around, in case > we end up not finding the next overlayfs bug until it is too late > for our project's delivery. At the cost of some security, you can disable this specific restriction via the sysctl knob: echo 0 > /proc/sys/kernel/yama/protected_nonaccess_hardlinks After the failure, you can see the (unhelpful) report in dmesg: [ 354.737598] non-accessible hardlink creation was attempted by: ln (fsuid 1000) However, I think the bug is actually with overlayfs. A similar problem was seen with aufs, but Andy fixed those. Based on the situation needed to reproduce it (non-writable), I think the condition that is failing in the hardlink restriction logic is this line: cred->fsuid != inode->i_uid But that makes no sense to me. Andy, is unionfs lying about the i_uid in the filesystem? -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Unperformant Restrictions for non-x86_32 archs
Hi Dieter,
I'm not sure I understand your request. The file you seem you mean is from
the Linux kernel package ("linux_3.2.0-17.27.diff.gz"), which collects all
the various patches Ubuntu carries for the kernel.
The routine you've quoted is from the NX-emulation patchset from:
http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu
More specifically, this is a fix for brk area collisions when doing
ASCII-armored ASLR of the text segment for ELFs that have been built with
PIE.
Are you seeing some performance loss related to this?
And what did you want changed?
Thanks,
-Kees
On Wed, Feb 29, 2012 at 09:19:48AM +, Dieter Miosga wrote:
> Please change in file linux_32.0-17.27.diff
> at line 5268, and all following and preceding occurences , to
>
> --- linux-3.2.0.orig/arch/x86/kernel/process.c
> +++ linux-3.2.0/arch/x86/kernel/process.c
> @@ -663,6 +663,16 @@
> unsigned long arch_randomize_brk(struct mm_struct *mm)
> {
> unsigned long range_end = mm->brk + 0x0200;
> -return randomize_range(mm->brk, range_end, 0) ? : mm->brk;
> +#ifdef CONFIG_X86_32
> +unsigned long bump = 0;
> +/* when using ASLR in arch_get_unmapped_exec_area, we must shove
> + the brk segment way out of the way of the exec area, since it
> + can collide with future allocations if not. */
> +if ( (mm->get_unmapped_exec_area == arch_get_unmapped_exec_area) &&
> + (mm->brk < 0x0800) ) {
> +bump = (TASK_SIZE/6);
> +}
> +return bump + (randomize_range(mm->brk, range_end, 0) ? : mm->brk);
> +#else
> +return randomize_range(mm->brk, range_end, 0) ? : mm->brk;
> +#endif
>
> }
>
>
> Sincerely,
> Dieter Miosga
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote:
> On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote:
> >I asked about this in IRC yesterday, and Colin Watson pointed me to
> >the computer-janitor utility, which is intended to handle this.
> >Seconds later, Barry Warsaw told me that computer-janitor should die
> >:-)
>
> c-j needs attention, but I'm not particularly motivated to give it what it
> needs. There's basic housekeeping, such as that the code for c-j is sprinkled
> between the update-manager and the computer-janitor packages, and even more
> important problems such LP: #458872. What's demotivating though is that in
> all the discussions we've had about the tool, most people think it's just not
> user-friendly enough given today's emphasis on software-center.
FWIW, this is the highly advanced system I use for my auto-updated VMs. It
keeps the latest 2 kernels:
OLD=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | \
awk '{print "linux-image-" $0}')
if [ -n "$OLD" ]; then
apt-get -qy remove --purge $OLD
fi
Be warned, of course, that if you don't reboot often, you can end up
removing the kernel you're running. :P
-Kees
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boot Speed Testing Results
On Mon, Dec 12, 2011 at 04:17:52PM -0500, Pete Graner wrote: > On 12/09/2011 12:06 PM, Kees Cook wrote: > >On Wed, Dec 07, 2011 at 01:23:21PM -0700, Patrick Wright wrote: > >>The Platform QA has started executing boot speed tests on the daily > >>ISOs. We are currently using the bootchart package to collect the > >>boot speed results. Those results can be reviewed from the Boot Speed > >>Report. [1] The results you see are still in progress, but its a good > >>idea of where we're heading. The Dell and Samsung are the most > >>up-to-date. > > > >Great! Thanks for getting these published. Are there plans to add other > >workloads? I would be very curious to see things like kernel build times, > >iobench, apache static and dynamic page serving latency, and power > >consumption for idle, dvd, audio, etc. > > In the near term future you have boot speed and we will be doing > power testing as well via a high end Fluke Network meter. That power > bits are still a work in progress but we should have something up in > the next few weeks. cking is the guy to talk to. Cool! That sounds great. I've long wanted to bust open some laptops and get some probes in there, but never find the time. :) > As far as benchmarking, load & stress tests, they are on the long > term roadmap for QA but not for this cycle. Okay, thanks. Is there any way for people to contribute tests that could get added to these reports? I know autotest has a "perf" output mode, but I haven't played with it much yet. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boot Speed Testing Results
Hi Patrick, On Wed, Dec 07, 2011 at 01:23:21PM -0700, Patrick Wright wrote: > Hello, > The Platform QA has started executing boot speed tests on the daily > ISOs. We are currently using the bootchart package to collect the > boot speed results. Those results can be reviewed from the Boot Speed > Report. [1] The results you see are still in progress, but its a good > idea of where we're heading. The Dell and Samsung are the most > up-to-date. Great! Thanks for getting these published. Are there plans to add other workloads? I would be very curious to see things like kernel build times, iobench, apache static and dynamic page serving latency, and power consumption for idle, dvd, audio, etc. Thanks! -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote: > non-pae has a ginormous and ugly NX emulation patch This is about dropping non-PAE support, not dropping non-NX support. The NX emulation patch must remain in the kernel since a large number of systems have PAE but not NX. You can see this in the table here: https://wiki.ubuntu.com/Security/Features#nx Dropping non-PAE just eliminates the top line in that table. NX-emu will still be needed. > that has consumed substantial maintenance resources in the past, I'm also curious about this claim, as you've expressed to me in the past that carrying it has been surprisingly trivial. In fact, since I'm the one maintaining it these days, it's actually going to require 0 resources from Canonical. ;) http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu > The kernel team has limited resources. Obviously I want to apply > what resources we have to the problems that affect the most > important platforms. Furthermore, I anticipate new ARM flavours in > the coming months which will take up any slack afforded by the loss > of non-PAE. I'm curious why pushing non-PAE to universe and leaving it in the main linux source package is a burden? Then people using non-PAE get automatic security updates without any hassle on anyone's part. This is what the Ubuntu Security Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html as well as the Ubuntu Platform Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html I'm not convinced there's enough evidence to say that dropping it from the main linux source package will actually save any time at all. -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report 2011-08-11
https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/823513 New upstream cairo-dock release, approved, merged, uploaded. https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/823514 New upstream cairo-dock-plug-ins release, approved, merged, uploaded. https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/unreportable-pkg-conflict/+merge/71264 Identified logic bug, requested a fix. Got fixed, approved, merged, uploaded. https://bugs.launchpad.net/ubuntu/+bug/817133 Reviewed and requested fixes for oneiric archive inclusion. https://bugs.launchpad.net/ubuntu/+source/glance/+bug/801299 Reviewed and rejected MIR for glance. https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/817995 Reviewed and approved p11-kit MIR. https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/800853 Reviewed and approved heimdal MIR. https://bugs.launchpad.net/ubuntu/+source/swift/+bug/819903 Reviewed, made small suggestion to packaging, and approved swift MIR. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot report: 2011-07-19
(Relocated from my scheduled time last week...) https://bugs.launchpad.net/ubuntu/+source/rng-tools/+bug/812121 https://code.launchpad.net/~sbeattie/ubuntu/oneiric/rng-tools/lp812121-linux-3.0/+merge/68215 Looks fine, merged, built, uploaded. UFW Debian sponsorship Reviewed, built, uploaded https://bugs.launchpad.net/ubuntu/+source/apport/+bug/811203 Assisted with patch creation. https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 https://code.launchpad.net/~pali/ubuntu/oneiric/kubuntu-default-settings/kubuntu-default-settings/+merge/63334 https://code.launchpad.net/~pali/ubuntu/oneiric/initramfs-tools/initramfs-tools/+merge/64373 No progress upstream, unfortunately. Cannot move forward until upstream takes the changes. https://code.launchpad.net/~hrw/ubuntu/oneiric/eglibc/fix-armhf-again/+merge/63258 Reviewed, already present in Oneiric eglibc. Marked as such. built, uploaded://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/mountall/oneiric-201106072111/+merge/63765 State unclear, asked for clarification. https://code.launchpad.net/~hypodermia/ubuntu/oneiric/compiz/fix-for-bug-301174/+merge/64632 Wanted someone working on compiz to review. Asked for review from smspillaz directly. https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/797894 Already been SRUed. Did verification, updated bug. https://code.launchpad.net/~fougner/ubuntu/oneiric/kdepim/fix-for-791635/+merge/65073 Still needs fixing. https://code.launchpad.net/~dpolehn-gmail/ubuntu/oneiric/pxlib/fix-755924-use-pkg-config/+merge/65151 Still needs fixing. https://code.launchpad.net/~oier/ubuntu/oneiric/latex-beamer/fix-for-bug-682202/+merge/65415 Found similar Debian bugs, and marked as "Needs Fixing" since the proposed solution doesn't look to be correct based on Debian bugs. https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/initramfs-tools/oneiric-201106221912/+merge/65551 Still needs fixing. https://code.launchpad.net/~neonofneophyte/ubuntu/oneiric/notification-daemon/fix-for-557887/+merge/65720 Still needs fixing. https://code.launchpad.net/~vanvugt/ubuntu/lucid/nvidia-graphics-drivers/fix-627022/+merge/66255 Still needs fixing. https://code.launchpad.net/~jtaylor/ubuntu/oneiric/ncbi-blast+/fix-803185/+merge/68268 https://bugs.launchpad.net/ubuntu/+source/ncbi-blast+/+bug/803185 Reviewed, approved, merged, built, uploaded. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report 2011-06-09
Hi, Here's what I worked through today: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/790854 reviewed and approved xen MIR https://bugs.launchpad.net/ubuntu/+source/apg/+bug/785682 reviewed and approved apg MIR https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/785680 reviewed and rejected accountsservice MIR https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/base-files/oneiric-201105041859/+merge/59981 Not actually ready for a merge, no action taken. https://code.launchpad.net/~marcelstimberg/ubuntu/natty/epdfview/fix-for-783109/+merge/61794 Needs fixing, no action taken. https://code.launchpad.net/~cairo-dock-team/ubuntu/oneiric/cairo-dock-plug-ins/2.3.0-2.1/+merge/61871 Reviewed, merged, uploaded. https://code.launchpad.net/~marcelstimberg/ubuntu/natty/epdfview/fix-for-783109/+merge/61794 https://launchpad.net/bugs/783109 Blocked by Oneiric sync request, no action taken. https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 Blocked by upstream submission, no action taken. https://code.launchpad.net/~abone/ubuntu/natty/popularity-contest/fix-742017/+merge/62411 Proposed merge needs additional work and Oneiric branch. Requested a fix. https://bugs.launchpad.net/ubuntu/+source/popularity-contest/+bug/742017 Already being worked on my slangasek, no action taken. https://code.launchpad.net/~genged/ubuntu/lucid/netcat-openbsd/dccp-support/+merge/62572 Needs Oneiric patches first. Requested a fix. https://code.launchpad.net/~vanvugt/ubuntu/oneiric/bcmwl/fix-776439/+merge/63192 Wrong merge target (has been uploaded to -proposed). Marked as merged. https://code.launchpad.net/~vanvugt/ubuntu/oneiric/bcmwl/fix-776165/+merge/63191 Wrong merge target (has been uploaded to -proposed). Marked as merged. https://bugs.launchpad.net/ubuntu/+source/gmemusage/+bug/370735 Bug already had additional information requested, but I feel a special responsibility to fixing stuff that was broken by compiler hardening. Updated patch and changelog, uploaded to oneiric. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Upstart helpers (abstract jobs and event aliases) for Oneiric
Hi James,
On Tue, Jun 07, 2011 at 03:00:03PM +0100, James Hunt wrote:
> == Proposal 2: Provide Abstract Jobs for Common Services ==
> [...]
> Option 1
> [...]
> For example, each display manager package would be updated such that its
> .conf file specified:
>
> envDISPLAY_MANAGER=y
> export DISPLAY_MANAGER
>
> Then, any job that requires a display manager could say:
>
> start on starting DISPLAY_MANAGER=y
> [...]
> Option 2
> Create a Job Configuration File that hard-codes the list of known
> service providers. For example for "display-manger", we could have:
>
> start on (starting gdm
> or (starting kdm
> or (starting lightdm
> or (starting lxdm
> or (starting slim
> or (starting wdm
> or starting xdm))
>
> stop on (stopping gdm
> or (stopping kdm
> or (stopping lightdm
> or (stopping lxdm
> or (stopping slim
> or (stopping wdm
> or stopping xdm))
>
> envABSTRACT_JOB=y
> export ABSTRACT_JOB
> [...]
>
> - We appear to have simply "moved the problem" since although we are no
> longer hard-coding the list of display managers in "plymouth.conf", we
> are hard-coding the list now in "display-manager.conf". However, we
> have gained by doing this since:
>
> - We have still created the level of abstraction desired.
> - We have contained the problem into a single file: we define the list
> of display managers *once*.
> - We don't need to update every Ubuntu (and potentially every Debian)
> package as would be required for "Option 1".
> - We *could* conceivably auto-generate "display-manager.conf" from the
> archive with a simple script which munged the output of:
>
> apt-cache search x-display-manager|awk '{print $1}'|sort
>
> - The "ABSTRACT_JOB" variable would allow other jobs to detect that a
> job was abstract (they shouldn't need to care, but just in case...)
> This also avoids the unwieldliness of "abstract-display-manager" (or
> even "abstract/display-manager" (were we to put the abstract jobs in
> /etc/init/abstract/ say).
What about merging the two options? I think it's a mistake to have
hardcoded lists; this is like having /etc/service.conf instead of
/etc/service.d/ for things to easily insert themselves into the system.
Imagine, instead:
start on (starting DISPLAY_MANAGER=y
or (starting gdm
or (starting kdm
or (starting lightdm
or (starting lxdm
or (starting slim
or (starting wdm
or starting xdm)))
Then anything not in the hardcoded list can just define itself as a
DISPLAY_MANAGER to be included, and everything else can still start on the
abstract job names too.
-Kees
--
Kees Cook
Ubuntu Security Team
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Vino should not be included in the default install
On Fri, Jun 03, 2011 at 11:36:03AM -0500, Mario Limonciello wrote: > On Fri, Jun 3, 2011 at 10:16, Bilal Akhtar wrote: > > I originally posted this message as [Bug 790009] on Launchpad. > > It was suggested that this list is a better place for the suggestion. > > -- > > > > Having "remote desktop" as an option in the default installation > > creates a security risk. > > > > It invites new users to enable it, not understanding the security > > implications. They then end up with unwanted connections to their > > machine. A quick look around the "security discussions" forum on > > ubuntuforums shows that this happens quite frequently. > > > > I propose that it should be removed from the LiveCD. If a remote connection > > program is needed, then something that*requires* SSH tunnelling could be > > provided. > > > > -- > > Jane Atkinson > > (Irihapeti) > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > > Removing sounds like a fairly heavy footed approach. If the UI to enable it > isn't informative enough to explain the security implications, perhaps that > UI should just be improved instead. The UI defaults to pretty reasonable settings. Unless those have changed since I've last looked, I don't think it's a concern. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, Jun 02, 2011 at 06:20:28PM +0100, Matt Zimmerman wrote: > On Thu, Jun 02, 2011 at 10:16:04AM -0700, Kees Cook wrote: > > On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote: > > > Quoting Matt Zimmerman (m...@ubuntu.com): > > > > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just > > > > debugging problems which will require root to fix. The most common is > > > > probably the traditional "what device node was assigned to that device I > > > > > > Nothing at all weird about that. > > > > Aren't we all supposed to use "udisks --enumerate" now? :) > > I hadn't used that before. You got my hopes up, and I thought it might turn > out to be a tool to map device nodes to meaningful descriptions of the > physical devices. Oh well. :-) Yeah, that's kind of my point; the information is scattered all over the place. "udisks --dump" has just about everything, but is a bit non-trivial to quickly visually scan, IMO. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote: > Quoting Matt Zimmerman (m...@ubuntu.com): > > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just > > debugging problems which will require root to fix. The most common is > > probably the traditional "what device node was assigned to that device I > > Nothing at all weird about that. Aren't we all supposed to use "udisks --enumerate" now? :) -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Fri, May 27, 2011 at 04:29:33PM +0100, Matt Zimmerman wrote: > On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote: > > I won't say it doesn't complicate things, but I would like to point out > > that everyone else's suggestion for this is to completely remove the values > > from the dmesg report itself, rendering it unavailable to any user, even > > root. > > It seems we are forced into this dichotomy because there is only one log, > which is mixing different types of information. Has anyone proposed > separating kernel debugging information from simple status logging, and > allowing the remainder to remain accessible to users? I don't think this would end up being sensible either, as the task of performing debugging may need access to both. I still don't see the problem of debugging as root. If you're not the system owner, you're not going to be able to _change_ the system in an effort to fix the problem you are debugging. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 11:49:45AM -0700, Steve Langasek wrote: > On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: > > In Oneiric, I'd like to change the default availability of yet another > > long-standing system debugging feature: dmesg. > > I think this is a bridge too far. dmesg is a very important tool for > debugging systems, and I am very concerned that this will impair my ability > to troubleshoot kernel problems on my hardware - perhaps under circumstances > where the system is so far gone that 'sudo' doesn't work. Which means I > would probably have to twiddle the sysctl bit, which means I won't get the > intended protections. If you are debugging a "sudo" failure, it's probably not the kernel's fault. :) If you just need to be root, you can reboot to single user and examine the kern.log file. If your disks are busted, you can reproduce after booting single user, etc. I won't say it doesn't complicate things, but I would like to point out that everyone else's suggestion for this is to completely remove the values from the dmesg report itself, rendering it unavailable to any user, even root. Systems that are misbehaving or under development can just always run with the dmesg_restrict bit off. A system that experiences a single unique failure where the kernel log can never be accessed seems like a very small corner-case to hold back a benefit to the rest of the distro's users. > > Kernel address leaks will become even more valuable to exploit authors > > once kernel base address randomization[4] lands in the kernel, and I > > want to make sure Ubuntu is prepared, well in advance of the next LTS, > > for this change. When the base address is randomized, "dmesg" must be > > privileged, or else the exactly offset is trivially visible (i.e. of > > the offset from "0xc100"): > > > $ dmesg | grep -m1 text > > [0.00] .text : 0xc100 - 0xc15112a1 (5188 kB) > > Why can't we simply change the kernel to not output this line when base > address randomization is in use? I think I've covered this in other emails -- the leaks are intentional and useful for debugging. Losing them permanently is not sensible. > > One unresolved problem is that the local default user (who is part of > > "admin") is also part of the "adm" group, which means these log files are > > visible without additional privileges: > > > -rw-r- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg > > -rw-r- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log > > > (And some system have a historically world-readable /var/log/dmesg that > > should be fixed...) Does anyone see any problems in removing the default > > user from the "adm" group? It seems to almost exclusively only be used for > > log file reading permissions... > > Yes, this is a BIG problem. The adm group is there precisely so that admins > don't have to use su/sudo and type a password to look at log files. If I'm > trying to debug a Network Manager problem on a system that uses > network-based authentication, not being in the adm group means I have to > wait for network timeouts before I can look at the logs to figure out what I > need to do to fix my network! Right, a fair point, and I think the better approach is what was suggested in another thread: just change these two files to group "root". -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, May 26, 2011 at 04:41:04PM +0100, Matt Zimmerman wrote: > On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: > > As we have continued to close kernel address leaks, the kernel syslog > > (dmesg) remains one of the last large places where information is being > > reported. As such, I want to close this off from regular users so that > > local kernel exploits continue to have an even harder time getting a > > foot-hold on vulnerabilities. And, as before, this is a tunable that you > > can change in /etc/sysctl.d/ if you do development work, like getting > > owned, etc. For the average user, this information is not needed. > > What are the ways in which kernel addresses are leaked through dmesg? Can > you provide some examples? Is it not feasible to avoid leaking addresses, > while still passing on all of the useful data in dmesg to users? Many net reports include specific heap allocation structures, Oops reports, boot-up reports, there are hundreds of places, and they're reported to dmesg for the specific purpose of being able to examine them later. Eliminating them from dmesg would be much much worse than making access to dmesg privileged. It goes from literally being unable to debug a problem to just needing to be root to do it. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 09:37:47PM +0200, Martin Pitt wrote: > Kees Cook [2011-05-25 12:05 -0700]: > > Currently, the upstream kernel folks have rejected filtering printk. > > That's not actually what I meant. Don't filter the outputs of printk() > with some regexps. I meant "just kill the printk() call that prints > the address". Why would you even need to printk() it if the very thing > it prints out is not meant to be seen in logs? Right. This is precisely what upstream has refused[1] to do. The problem is that dmesg is just a log. The contents can't be adjusted based on who is viewing it like (like has been done for the %pK sprintf uses in /proc, /sys, etc). Things like Oops reports will go to dmesg, which are utterly useless without all their addresses intact, etc. The only way to close this entire area of leaks is to make dmesg a privileged resource, and that is possible using the dmesg_restrict stuff (created for this very purpose). -Kees [1] http://marc.info/?l=linux-netdev&m=128915072325450&w=2 -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 09:36:16PM +0200, Martin Pitt wrote: > So if needed, you can implement attach_dmesg() with > attach_root_command_outputs(). Ah, perfect. That'll be the way to go, then. > But aside from that I do agree with Steve that it both seems a lot > safer as well as more convenient and less intrusive to just filter out > the address from the printk in the first place, instead of disallowing > non-admins to see some useful debugging (like errors on removable disk > drives, what the heck is currently wrong with their wifi, etc.) This just isn't going to happen, unfortunately. The number of leaks is giant, and upstream is completely unwilling to filter printk() so far. I wanted to get this turned on now because it will be needed once we have kernel base address randomization, and if that happens for the LTS, I didn't want to have to make the dmesg privilege transition also in LTS. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 11:49:45AM -0700, Steve Langasek wrote: > I'd much rather we find a way to fix it so the information *logged* to these > files isn't privileged to the point that it can't be exposed to admins, > instead of gutting admins' ability to make use of these crucial logs. Currently, the upstream kernel folks have rejected filtering printk. However, there has been some noise recently about making a distinction between the "actual" address and the "unrandomized" address. (As in, printk would be forced to use a new %p modifier for all kernel addresses, and that modifier would report the "unrandomized" address by default, keeping the actual address secret even from dmesg. We'll see how this progresses... -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 08:27:01PM +0200, Martin Pitt wrote: > Hello Kees, all, > > Kees Cook [2011-05-25 10:03 -0700]: > > Yeah, the problem is that it's not a one-time question (see the bug above), > > so that each time we need privileges to gather data, apport will prompt for > > the sudo password _again_. :( > > One word: attach_root_command_outputs() :) > > Hooks can and should use this apport.hookutils function if they have > several log files to attach. But the existing code for attach_dmesg() doesn't really fold into that very well since it's reading the old /var/log/dmesg file, then running "dmesg" itself, etc. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 06:41:52AM +0200, Martin Pitt wrote: > Kees Cook [2011-05-24 11:46 -0700]: > > $ dmesg | grep -m1 text > > [0.00] .text : 0xc100 - 0xc15112a1 (5188 kB) > > Would it be possible to have the kernel just not log the addresses in > the first place? It seems kind of pointless to make a big effort of This was debated at length with upstream, and ultimately, they declared that printk()s should not be filtered at all, and that as a compromise, DMESG_RESTRICT was created so that all the printk output (dmesg) could be treated as privileged. > randomizing these and then yell it out loudly where it lands in any > kind of log file. People might also have a custom rsyslog > configuration etc. which we can't even fix on upgrades. True, this will not be perfect, but education about why dmesg output should be considered privileged will be the only sane way to handle non-default upgrades, I think. We could also send patches to the various syslog implementations to treat dmesg with 0600 perms, etc. > So wouldn't it be enough to have the actual addresses somewhere in > /proc/ in a 0400 file, and just purge them from printk()s? Everything (in theory) in /proc and /sys is already being filtered using the %pK kernel-sprintf() modifier. (There are still likely more to be added, but the bulk of it is done.) So, as root, you can still see these values. This was already done in Natty, since it disrupted very little. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
Hi Brad, On Tue, May 24, 2011 at 05:53:22PM -0700, Brad Figg wrote: > On 05/24/2011 04:49 PM, Kees Cook wrote: > >On Tue, May 24, 2011 at 03:59:53PM -0700, Bryce Harrington wrote: > >>On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: > >>>Hello! > >>> > >>>In Oneiric, I'd like to change the default availability of yet another > >>>long-standing system debugging feature: dmesg. > >>> > >>>Thoughts, flames, etc? > >> > >>See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some > >>sudo caching problems apport has had to work around which might pose > >>some complications here as well. > > > >Yeah, that bug is pretty ugly. :) > > > >>Can you outline your plans for updating apport in conjunction with this > >>change? > > > >Well, it needs to be larger than just apport. A lot of things call dmesg, > >and I can't fix them all, but getting people educated about what has > >changed is the first step. > > > >As for apport itself, I do not have an immediate solution. hookutils.py's > >attachmesg() will need privs, and that's used all over the place > >(attach_alsa(), attach_hardware()): > > > >$ find -P /usr/share/apport -type f | xargs egrep -H > >'attach_(hardware|alsa|dmesg)' | cut -d: -f1 | sort -u | wc -l > >33 > > > >I'm open to suggestions. > > > >-Kees > > > > Just FYI, the kernel hooks already ask for permissions to get the > ACPI tables. Yeah, the problem is that it's not a one-time question (see the bug above), so that each time we need privileges to gather data, apport will prompt for the sudo password _again_. :( Martin, do you have any thoughts on ways to deal with this? You did a lot of digging in that bug, and nothing really presented itself as a clean solution... -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 08:07:14AM -0400, Scott Kitterman wrote: > On Tuesday, May 24, 2011 06:00:17 PM Clint Byrum wrote: > > Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011: > > > One unresolved problem is that the local default user (who is part of > > > "admin") is also part of the "adm" group, which means these log files are > > > visible without additional privileges: > > > > > > -rw-r- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg > > > -rw-r- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log > > > > > > (And some system have a historically world-readable /var/log/dmesg that > > > should be fixed...) Does anyone see any problems in removing the default > > > user from the "adm" group? It seems to almost exclusively only be used > > > for log file reading permissions... > > > > > > Thoughts, flames, etc? > > > > +1 > > > > I've always been a bit surprised at how much I can see in /var/log when > > logged into a brand new box as the initial admin user. I think users are > > accustomed to sudo when debugging issues, and I'm comfortable with saying > > that reading /var/log/* is just one more thing you need to use sudo for. Clint, what do you think of the proposal below? It's a less dramatic change, which might be more well received ultimately. > This doesn't match how I think of it, but I may be unusual (in this regard - > otherwise I think that's already well established). I have tended to view > sudo/root as "ooh, be careful not to break the system" and "understand the > system" as something I should do as a normal user (with limited exceptions). > > Currently on the 11.04 system I'm typing this on, I have: > > -rw-r- 1 root adm53466 2011-05-24 13:19 dmesg > > /var/log has a mix of files owned by group root and group adm. Instead of > removing normal user access to all the files in /var/log, couldn't we just > change the group of dmesg* to root? > > I don't know about other GUI tools, but Kubuntu's userconfig gives a checkbox > to "Access system logs" that adds the user to adm. If we're fundamentally > changing how system logs are accessed we'll need to change that. Other GUI > user configuration tools should also be checked for this (and appropriate > work > items added to the spec. Yeah, same for Gnome (adm group checkbox). Just changing the specific log file permissions does seem to be the "least surprising" method to deal with this. I will go that route, thanks. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Tue, May 24, 2011 at 03:59:53PM -0700, Bryce Harrington wrote: > On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: > > Hello! > > > > In Oneiric, I'd like to change the default availability of yet another > > long-standing system debugging feature: dmesg. > > > > Thoughts, flames, etc? > > See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some > sudo caching problems apport has had to work around which might pose > some complications here as well. Yeah, that bug is pretty ugly. :) > Can you outline your plans for updating apport in conjunction with this > change? Well, it needs to be larger than just apport. A lot of things call dmesg, and I can't fix them all, but getting people educated about what has changed is the first step. As for apport itself, I do not have an immediate solution. hookutils.py's attachmesg() will need privs, and that's used all over the place (attach_alsa(), attach_hardware()): $ find -P /usr/share/apport -type f | xargs egrep -H 'attach_(hardware|alsa|dmesg)' | cut -d: -f1 | sort -u | wc -l 33 I'm open to suggestions. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: blueprint priorities
On Tue, May 24, 2011 at 03:03:54PM -0700, Allison Randal wrote: > I'm looking for more details on how people use blueprints, particularly > what the blueprint priorities mean. > > If there's a page on this already, let me know and I'll work on getting > it a higher profile so it appears on Google/wiki.ubuntu.com searches. If > we don't have it documented yet, does this list map to how you use the > priorities? > > Essential - Must happen in this cycle > > High - Desirable in this cycle > > Medium - Would like to happen in this cycle > > Low - Likely to be dropped from this cycle > > Rejected - Not considered in this cycle > > > If that's not quite right, how do you use the priorities, and do you > have some suggestions on better definitions? This is basically how the security team works, yes. I would probably replace "Desirable in this cycle" with "Important for this cycle" or maybe "Likely in this cycle", otherwise it sounds too close to "Medium" to me. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Enabling the kernel's DMESG_RESTRICT feature
Hello! In Oneiric, I'd like to change the default availability of yet another long-standing system debugging feature: dmesg. Since Linux 2.6.37, CONFIG_DMESG_RESTRICT (/proc/sys/kernel/dmesg_restrict) has existed[1], but the default in Ubuntu has been to leave "dmesg" available to unprivileged users (i.e. lacking the CAP_SYSLOG capability, changed in 2.6.38[2]). I brought this up[3] in November, but ultimately decided to wait until we had more important reasons to enable it by default. As we have continued to close kernel address leaks, the kernel syslog (dmesg) remains one of the last large places where information is being reported. As such, I want to close this off from regular users so that local kernel exploits continue to have an even harder time getting a foot-hold on vulnerabilities. And, as before, this is a tunable that you can change in /etc/sysctl.d/ if you do development work, like getting owned, etc. For the average user, this information is not needed. Kernel address leaks will become even more valuable to exploit authors once kernel base address randomization[4] lands in the kernel, and I want to make sure Ubuntu is prepared, well in advance of the next LTS, for this change. When the base address is randomized, "dmesg" must be privileged, or else the exactly offset is trivially visible (i.e. of the offset from "0xc100"): $ dmesg | grep -m1 text [0.00] .text : 0xc100 - 0xc15112a1 (5188 kB) Now, making "dmesg" a privileged command will require extensive changes to documentation, debug-info-gather tools (e.g. users of "dmesg" like Apport), etc. The syslog daemon already has the needed privileges since it does more than just read the klog buffer (see [3] for a full list of klogctl() users). As with last year's ptrace changes[5], I plan to patch the userspace tools (i.e. "dmesg") themselves to produce a useful error message instead of what it current reports when /proc/sys/kernel/dmesg_restrict is set to "1": $ dmesg klogctl: Operation not permitted I think something like this will be used: $ dmesg klogctl: Operation not permitted The kernel syslog is only available to privileged users. For more details, see /etc/sysctl.d/10-dmesg.conf And then there will be extended information in that file, etc. One unresolved problem is that the local default user (who is part of "admin") is also part of the "adm" group, which means these log files are visible without additional privileges: -rw-r- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg -rw-r- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log (And some system have a historically world-readable /var/log/dmesg that should be fixed...) Does anyone see any problems in removing the default user from the "adm" group? It seems to almost exclusively only be used for log file reading permissions... Thoughts, flames, etc? -Kees [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eaf06b241b091357e72b76863ba16e89610d31bd [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=38ef4c2e437d11b5922723504b62824e96761459 [3] https://lists.ubuntu.com/archives/kernel-team/2010-November/013499.html [4] https://lkml.org/lkml/2011/5/22/99 [5] https://lists.ubuntu.com/archives/ubuntu-devel/2010-May/030797.html -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boost Transition
On Tue, May 03, 2011 at 02:00:26PM +0100, Colin Watson wrote: > On Fri, Apr 29, 2011 at 12:48:54PM +0200, Pau Garcia i Quiles wrote: > > This version of Boost (along with many other packages, some of them > > mine) will be broken once OpenSSL 1.0.0d, which disables SSLv2, is > > accepted into Oneiric. > > The version of OpenSSL in Natty already disabled SSLv2. Just for clarity, Natty (and Maverick) disabled v2 in OpenSSL by way of erroring out on the routines (but did not break ABI). The 1.0.0d openssl removes the v2 ABI completely. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /etc/init.d/* status .. what to do when transitioning to an upstart job?
On Thu, Dec 16, 2010 at 08:41:56AM +0100, Thierry Carrez wrote: > Kees Cook wrote: > >> /etc/service/status.d > >> > >> And if one exists for the job name, run it, otherwise just run the > >> upstart status and provide an LSB compatible return code. > >> > >> This would also allow for the post-start stanza to call the same code if > >> it is needed. > >> > >> Does anyone have strong thoughts on this? Given the service.d approach, > >> it would seem the correct course of action is to open a feature request > >> against sysvinit, document it in our upstart job writing best practices, > >> and to document this feature in the server guide. > > > > Why should this be external to upstart? This seems to me like a clearly > > missing feature in upstart itself. (i.e. a "status" stanza for services > > that need a non-passive check.) > > +1 on an optional, specific "status" stanza in upstart scripts. When > present, it could be automatically called as a post-start before > "started" is emitted, and would also be called when "status" is used. Has anything happened with this? Would this make a good UDS topic? -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default Desktop Experience for 11.04
On Thu, Apr 14, 2011 at 02:17:47PM -0500, Ted Gould wrote: > But, I'd also love to see the requirements for Universe be something > higher than just the DFSG. For instance, I believe Debian requires > everything in /usr/bin to have a man page. Many of these I see as the > modern desktop equivalent of having a man page. eXtreme +1 And not just universe. I would love this requirement to be more strictly enforced in the entire Ubuntu archive. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default Desktop Experience for 11.04
Hi Rick, On Thu, Apr 07, 2011 at 06:38:27PM -0700, Rick Spencer wrote: > Back at UDS for 11.04 in Orlando, Mark set the goal of using Unity by > default on the Ubutu desktop. Given the current course of development, > it appears that we are going to achieve this goal, and Unity will stay > the default for 11.04. Before anything else, I want to say that everyone working on Unity has been rocking, and their efforts are to be applauded. I hope they will forgive me for the rest of this email. :P I was specifically asked to re-try Unity for today. I want to say up front that I don't really see myself as Unity's target audience, and I have had long-term problems with compiz's usability vs how I want to work. Regardless, this is my report. :) I had to finish my Patch Pilot shift first, but then spent the afternoon with Unity (and more frustratingly, compiz). Compared to earlier in the devel cycle, things are greatly improved from my perspective. But then I was fighting Intel driver regressions and plenty of other problems beyond just unity and compiz. At the time, compiz crashed every 5 minutes, and I couldn't go more than 30 minutes of this without just giving up so I could actually get work done. This afternoon, compiz only crashed twice, and I was able to use Unity for a few hours (most of the time spent filing bugs, see below). I am still using Unity at the moment, but bug 755156 has gotten so bad, I may have to go back to metacity soon. I still find it alarming that compiz crashes at all. I do not remember metacity crashing on me in several years, for example. I've previously opened a lot of bugs against compiz (most still open), so I was nervous to really dive into this and document my last few hours. Here are my notes, along with my crashes... - window resizing does not include window size information (especially critical for terminal geometry sizes) - workaround: ccsm / Utility / Resize Info (enable) - clicking this option crashed compiz (filed as LP: #755167) - apport did not pop up - is the notifier applet missing? - if so, how will people get security updates? - cannot reproduce crash - "unity --reset" does not reset themes (had to select Ambience manually to have a sane-looking indicator area). - cannot pick minimized applications out of launcher without 2 clicks in very separate screen locations - old interface: window switcher click for list, move slightly to desired window title, click again, done. - no visibility of window titles at all, actually - right-click on launcher produces popup that could not be interacted with - problem went away for no reason - cannot reproduce - did not file bug - right-click on launcher disables auto-hide. clicking other places outside the launcher does not close the pop-up. - problem went away for no reason - cannot reproduce - did not file bug - crashed when clicking launcher for Terminator while Terminators were running - all windows relocated the width of the top panel lower on unity restart - apport still did not pop up - filed mine as LP: #755146 - 7 other identical crashes - cannot reproduce crash - focus-follows mouse setting has no effect on launcher autohide speed - did not file bug - launcher autohides after raising a window even if mouse is still on it - did not file bug - desktop items are shifted right by the width of the launcher and cannot be moved back into position (dragging them causes the launcher to appear!) - didn't file, suspect this is by design - alt-tab is a disaster of sluggish responsiveness and frustrating timing (my long-standing objection to the compiz task switcher...) - best approximation of the snappy and responsive metacity-like alt-tabbing: - static application switcher behavior popup window delay = 0 speed = 50 timestep = 0.1 appearance opacity = 100 highlight mode = show rectangle - cannot find a way to get rid of the center window "preview" animations :( - focus-follows mouse happens after an alt-tab, defocusing selected window, even when not using mouse, but only some times, making me crazy - filed as LP: #755156 with video of behavior - windows disappear while dragging at/in the top panel, firefox stops rendering and performs freaky window clipping - reported as LP: #755152 with video of behavior - interacting with some fullscreen apps (xine) triggers inconsistent launcher unhiding - reported as LP: #755160 with video of behavior Marc Deslauriers is trying to convince me that focus-follows-mouse is evil, but since I'm neither using a touch-screen nor a touch-pad, I can't agree. Until I see something as convincing as this[1], I'll keep using it. :) Thanks! -Kees [1] http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ -- Kees Cook Ubuntu Security Team -
Patch Pilot report 2011-04-08
https://code.launchpad.net/~psusi/ubuntu/natty/upower/sleep/+merge/54093 No action to be taken -- why is it visible in the queue? https://code.launchpad.net/~psusi/ubuntu/natty/indicator-session/sleep/+merge/54094 Depends on 54093, so cannot be merged. Is there no way to define blockers for merges? https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/sleep/+merge/54095 No action to be taken -- why is it visible in the queue? https://bugs.launchpad.net/ubuntu/+source/dates/+bug/696658 Since upstream has not responded and we're close to release, I've created a cdbs patch and changelog and uploaded the fixed package. https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/697999 https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/698007 Related bugs, asked superm1 to review them, as the patch seems to fix real problems, but needs someone more familiar with the code. https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/upstart-job-change-restart/+merge/52547 This has been merged into the upcoming branch already: http://bazaar.launchpad.net/~jamesodhunt/ubuntu/natty/upstart/fix-chroot-sessions/revision/1307 Marked as merged to drop from the sponsor queue. https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/712892 This has been deferred to upstream, so I unsubscribed sponsors. https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/proposed-2011.03.2/+merge/54277 It's not clear what's needed for this. I asked slangasek to take a quick look. https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/752924 https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/735548 Looks fine, merged, built, uploaded. https://bugs.launchpad.net/ubuntu/maverick/+source/nautilus/+bug/662194 https://code.launchpad.net/~psusi/ubuntu/maverick/nautilus/openwith/+merge/53563 https://code.launchpad.net/~psusi/ubuntu/lucid/nautilus/openwith/+merge/53562 Asked mdeslaur to add SRU justification and testcase. Built packages, merged branches, and uploaded to -proposed. https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/xdg-utils/natty-201104080911/+merge/56901 Trivial typo fix, merged and uploaded. https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/739760 Updated patch to do a slightly cleaner build, uploaded, forwarded to Debian. https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/738687 This is already scheduled for upload by RAOF, so I updated the bug status and commented on it. https://code.edge.launchpad.net/~cmiller/ubuntu/natty/desktopcouch/1.0.7-0u1/+merge/57014 Merged, built, uploaded. https://code.launchpad.net/~dobey/ubuntu/natty/banshee/fix-and-amz/+merge/57016 Waiting for rebase on recently uploaded banshee. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bug or feature ...
On Wed, Apr 06, 2011 at 02:53:46PM -0700, Kees Cook wrote:
> On Wed, Apr 06, 2011 at 05:35:07PM -0400, Scott Kitterman wrote:
> > He offers this as a test case:
>
> I can confirm the behavior difference between maverick and natty by doing
> this:
>
> while ./testcase.pl ; do echo -n . ; done
>
> On maverick, this runs forever. Natty immediately fails:
>
> Parent 792
>
> Child 793
> .bind: Address already in use at ./testcase.pl line 9.
>
>
> I hope this is a Net::Server delta and not a kernel delta.
This looks like a kernel bug to me. I can reproduce it with C as well.
$ ./testcase
parent: 3781
before:
tcp0 0 0.0.0.0:12345 0.0.0.0:* LISTEN
after:
child: 3786
$ ./testcase
bind: Address already in use
$ kill 3786
$ ./testcase
parent: 3810
before:
tcp0 0 0.0.0.0:12345 0.0.0.0:* LISTEN
after:
child: 3817
:(
--
Kees Cook
Ubuntu Security Team
/* Author: Kees Cook
* Copyright 2011 Canonical, Ltd
* License: GPLv2
*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PORT 12345
int main(int argc, char * argv[])
{
struct sigaction reaper;
struct protoent *proto;
struct sockaddr_in saddr;
int server, on=1;
char cmd[80];
if (!(proto=getprotobyname("tcp"))) {
perror("getprotobyname");
return 1;
}
if ((server = socket(PF_INET, SOCK_STREAM, proto->p_proto))<0) {
perror("socket");
return 1;
}
if (setsockopt(server, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) {
perror("setsockopt");
return 1;
}
memset(&saddr, 0, sizeof(saddr));
saddr.sin_family = AF_INET;
saddr.sin_addr.s_addr = htonl(INADDR_ANY);
saddr.sin_port= htons(PORT);
if (bind(server, (struct sockaddr *) &saddr, sizeof(saddr)) < 0) {
perror("bind");
return 1;
}
if (listen(server,5)<0) {
perror("listen");
return 1;
}
printf("parent: %d\n", getpid());
printf("before:\n");
sprintf(cmd, "netstat -an | grep :%d", PORT);
system(cmd);
int pid = fork();
if (pid == 0) {
printf("child: %d\n", getpid());
sleep(100);
exit(0);
}
shutdown(server, SHUT_RDWR);
printf("after:\n");
system(cmd);
return 0;
}
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bug or feature ...
Hi Scott, On Wed, Apr 06, 2011 at 05:35:07PM -0400, Scott Kitterman wrote: > He offers this as a test case: I can confirm the behavior difference between maverick and natty by doing this: while ./testcase.pl ; do echo -n . ; done On maverick, this runs forever. Natty immediately fails: Parent 792 Child 793 .bind: Address already in use at ./testcase.pl line 9. I hope this is a Net::Server delta and not a kernel delta. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: multiarch library support in Natty and Oneiric
On Mon, Mar 21, 2011 at 11:30:36PM -0700, Steve Langasek wrote: > Well, it's been a long time coming, but it's finally here. As of today, it > is possible to install library packages of other architectures on your natty > system through multiarch. This is excellent! \o/ > http://wiki.debian.org/Multiarch/Implementation > [...] > And tune in next week for the documentation on how to configure your system > to use multiarch packages now that we have them. :-) I've jumped ahead in the schedule and taken your notes from IRC on how to do this and added a small section to the above page. :) -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot report: 2011-03-10
http://people.canonical.com/~ubuntu-security/d2u/ - requested sync of pywebdav in natty - security fake-synced pywebdav into maverick - security fake-synced dtc into karmic https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/722815 Rejected patch, instead updated documentation and uploaded fix. Got hung up briefly on https://bugs.launchpad.net/launchpad/+bug/732638 https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/711549 Upstream is waiting for better kernel interface. May have already been solved with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550316 so marked incomplete and asked reporter to retest. https://bugs.launchpad.net/ubuntu/+source/ubuntu-netbook-default-settings/+bug/688010 Looks reasonable. Adjusted version for ubuntu-native pkg, build tested and uploaded. https://bugs.launchpad.net/udisks/+bug/460713 Linked to upstream report. Fix looks sane to me; add quilt patch, DEP3, build tested and uploaded. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/651886 Fix looks sane to me. Merged into upstream bzr tree, build tested and uploaded. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/591753 Hook seems functional. Merged into bzr tree, built, install tested, and uploaded. https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/667275 Found upstream commits that matched, included additional fixes. Build tested and uploaded. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: draft of natty toolchain transition guide
Hi Allison, On Tue, Jan 11, 2011 at 07:49:22PM -0600, Allison Randal wrote: > I'm working on a guide to help developers/packagers make the > transition to the new versions and default options in GCC and Python > for Natty: > > https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition > > This is a draft, and may change while you're looking at it (I'm > adding a section on makefiles at doko's suggestion). All comments, > suggestions, and corrections welcome. This is good and looks like a slightly similar document I keep up to date for the compiler's default flag for security hardening: https://wiki.ubuntu.com/CompilerFlags -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: changing perms on /sys/kernel/debug by default
On Tue, Feb 22, 2011 at 03:46:36PM -0800, Kees Cook wrote:
> On Tue, Feb 22, 2011 at 03:37:27PM -0800, Bryce Harrington wrote:
> > On Tue, Feb 22, 2011 at 03:16:39PM -0800, Kees Cook wrote:
> > > While I'd like to just not compile debugfs into the Ubuntu kernels at all,
> > > it seems that there is a fair bit of push-back on this idea. Instead, the
> > > dangerous /sys/kernel/debug/acpi/custom_method interface has been removed
> > > as the most problematic of all the interfaces (it allows writing arbitrary
> > > kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions).
> > >
> > > Since debugfs should not be required for a production system[1], I'd like
> > > to remove it from mountall's default fstab. To get there, the first step
> > > is
> > > to make /sys/kernel/debug only accessible by the root user. Unfortunately,
> > > it does not take a "mode=" mount option like tmpfs does, so mountall has
> > > been adjusted[2] to set the mode after mounting instead.
> > >
> > > - intel_gpu_dump
> > > Manpage states it should only be run as root.
> > >
> > > * xserver-xorg-video-intel
> > > Apport hook (should be updated to use root privs).
> >
> > I believe it does already, no? It gets triggered by the kernel via an
> > upstart hook.
> >
> > Due to the nature of GPU lockups, we can't prompt the user for root
> > password or something at the point it gets triggered; the system's
> > locked up.
>
> Ah, yes. If it's spawning from the X process context, this should be done
> already.
>
> > We get the majority of our value out of the apport hook during
> > development. So if you wanted to make debugfs be enabled only during
> > release, and switch it off after beta, we could work with that.
>
> Based on the above, it should all Just Work for the GPU case.
Just to confirm; yes it should be fine. Bryce pointed out on IRC that this
is called through /lib/udev/rules.d/40-xserver-xorg-video-intel.rules:
SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1",
RUN+="/usr/share/apport/apport-gpu-error-intel.py"
And that's running as root to collect the debugfs bits. Done! :)
-Kees
--
Kees Cook
Ubuntu Security Team
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: changing perms on /sys/kernel/debug by default
On Tue, Feb 22, 2011 at 03:37:27PM -0800, Bryce Harrington wrote: > On Tue, Feb 22, 2011 at 03:16:39PM -0800, Kees Cook wrote: > > While I'd like to just not compile debugfs into the Ubuntu kernels at all, > > it seems that there is a fair bit of push-back on this idea. Instead, the > > dangerous /sys/kernel/debug/acpi/custom_method interface has been removed > > as the most problematic of all the interfaces (it allows writing arbitrary > > kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions). > > > > Since debugfs should not be required for a production system[1], I'd like > > to remove it from mountall's default fstab. To get there, the first step is > > to make /sys/kernel/debug only accessible by the root user. Unfortunately, > > it does not take a "mode=" mount option like tmpfs does, so mountall has > > been adjusted[2] to set the mode after mounting instead. > > > > - intel_gpu_dump > > Manpage states it should only be run as root. > > > > * xserver-xorg-video-intel > > Apport hook (should be updated to use root privs). > > I believe it does already, no? It gets triggered by the kernel via an > upstart hook. > > Due to the nature of GPU lockups, we can't prompt the user for root > password or something at the point it gets triggered; the system's > locked up. Ah, yes. If it's spawning from the X process context, this should be done already. > We get the majority of our value out of the apport hook during > development. So if you wanted to make debugfs be enabled only during > release, and switch it off after beta, we could work with that. Based on the above, it should all Just Work for the GPU case. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
changing perms on /sys/kernel/debug by default
Hi, While I'd like to just not compile debugfs into the Ubuntu kernels at all, it seems that there is a fair bit of push-back on this idea. Instead, the dangerous /sys/kernel/debug/acpi/custom_method interface has been removed as the most problematic of all the interfaces (it allows writing arbitrary kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions). Since debugfs should not be required for a production system[1], I'd like to remove it from mountall's default fstab. To get there, the first step is to make /sys/kernel/debug only accessible by the root user. Unfortunately, it does not take a "mode=" mount option like tmpfs does, so mountall has been adjusted[2] to set the mode after mounting instead. In the interests of completeness, here are the tools in main that use debugfs, with stuff that needs updating (only Apport hooks) marked with a star: - intel_gpu_dump Manpage states it should only be run as root. - libpcap Only used as root for USB monitoring. * mtdev Apport hook (should be updated to use root privs). - nmap Only used as root for USB monitoring. - ocfs2-tools Only used as root for OCF2 debugging. - powertop Only used as root. - qemu-kvm kvm_stat has no manpage, seems to be designed as a "vmstat" for kvm. These statistics should likely come from /sys. Running as root seems fine. - redhat-cluster Only used as root. - ureadhead Runs as root, but this tool already uses /var/lib/ureadahead/debugfs if the other path is missing. I've changed[3] the permissions on this so that normal users cannot see the mountpoint. - usbutils Uses /dev/bus/usb for "lsusb", but "usb-devices" wants debugfs. This information should not come out of debugfs. Requiring root seems okay. * utouch-geis Apport hook (should be updated to use root privs). * xserver-xorg-video-intel Apport hook (should be updated to use root privs). - blktrace Only used as root. Thanks, -Kees [1] https://lkml.org/lkml/2011/2/22/372 [2] https://lists.ubuntu.com/archives/natty-changes/2011-February/008110.html [3] https://lists.ubuntu.com/archives/natty-changes/2011-February/008100.html -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Restructuring ubuntu-dev-tools?
On Wed, Jan 26, 2011 at 09:54:54PM +0100, Benjamin Drung wrote: > mk-sbuild I've opened an sbuild bug for including it there now. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot 2011-02-09
Hi, Just finishing my Patch Pilot day now. Here are some things I worked on, with notes: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/714838 Pass on the sync, as it seems not worth the risk to Natty. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/486154 Upstream hasn't agreed on a workable patch, so reject backporting. https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/713855 Merge is small, but the one patch needs updating, based on the upstream review of it. Got updated, reviewed, and uploaded the merge. https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/576949 Patch looks good, uploaded to -proposed. https://code.launchpad.net/~micahg/ubuntu/natty/pidgin/2.7.9-2/+merge/48721 The contents of the merge look okay to me. The changelog should be updated to include the whole delta between Debian and Ubuntu, but once that's done, I'd be happy to upload it. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/572110 Colin is already working out a saner approach. https://code.launchpad.net/~mathieu-tl/ubuntu/natty/plymouth/lsb-release-version/+merge/45095 Looks good, asked slangasek to review it again, and he had just merged it. https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/restore-re-exec-code/+merge/45295 Looks fine. Merged and uploaded. https://bugs.launchpad.net/ubuntu/+source/drupal6/+bug/539056 Copied to -proposed for verification. https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/702637 Set to Incomplete until until dep MIRs are finished. https://bugs.launchpad.net/ubuntu/+source/twiki/+bug/709401 Copied to -proposed for verification. https://bugs.launchpad.net/ubuntu/lucid/+source/cacti/+bug/599892 Uploaded Lucid to security-proposed. https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/690644 https://bugs.launchpad.net/bash-completion/+bug/652104 Uploaded to Maverick -proposed. https://code.launchpad.net/~clint-fewbar/ubuntu/natty/mountall/fix-mounted-tmp/+merge/48681 Discussed some additional changes, merged and uploaded. https://code.launchpad.net/~bkbox/ubuntu/maverick/munin/fix-for-699967/+merge/48984 https://bugs.launchpad.net/ubuntu/maverick/+source/munin/+bug/699967 Updated version in changelog to follow SRU standards, uploaded to -proposed. Thanks, -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Shall we hide the GUI for Hibernate in Natty?
Hi, On Mon, Jan 31, 2011 at 04:41:03PM -0500, Mackenzie Morgan wrote: > On Mon, Jan 31, 2011 at 4:34 PM, Kees Cook wrote: > > On Mon, Jan 31, 2011 at 04:24:11PM -0500, Mackenzie Morgan wrote: > >> On Mon, Jan 31, 2011 at 3:00 PM, Marc Deslauriers > >> wrote: > >> > I haven't actually tried this in a long time, but what happens with > >> > current Ubuntu when the battery drains out while suspended? > >> > >> It turns off. > >> > >> > Does the > >> > laptop wake up and enter hibernation to prevent data loss? > >> > >> No, but the disk does sync before suspend, so corruption isn't a > >> worry, just... "oops I didn't save before suspending." > > > > My newer laptop supports "hybrid" mode, and it will come out of suspend and > > then hibernate when the battery is critically low after being suspended for > > a long time. Extremely handy. > > I know some hardware has BIOS support for that, but I thought the OS > needed to understand it too and that Ubuntu was in "not yet" state on > that. Is this new? I'm not sure; I just know that I suspended my laptop and when I came back a week later the battery was dead. I plugged it in, booted, and it prompted for the disk password, and then unhibernated. Magic! I haven't actually investigated its mechanisms. I assumed that it would just unsuspend, and then g-p-m would freak out over the state of the battery and do a hibernate. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Shall we hide the GUI for Hibernate in Natty?
On Mon, Jan 31, 2011 at 04:24:11PM -0500, Mackenzie Morgan wrote: > On Mon, Jan 31, 2011 at 3:00 PM, Marc Deslauriers > wrote: > > I haven't actually tried this in a long time, but what happens with > > current Ubuntu when the battery drains out while suspended? > > It turns off. > > > Does the > > laptop wake up and enter hibernation to prevent data loss? > > No, but the disk does sync before suspend, so corruption isn't a > worry, just... "oops I didn't save before suspending." My newer laptop supports "hybrid" mode, and it will come out of suspend and then hibernate when the battery is critically low after being suspended for a long time. Extremely handy. > > Will the > > removal of hibernation support from the kernel result in data loss when > > battery runs out during suspend? I think there's a difference between > > removing the hibernate button and removing hibernate completely if > > that's the case. In my case, yes. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Shall we hide the GUI for Hibernate in Natty?
On Mon, Jan 31, 2011 at 11:04:22AM -0800, Rick Spencer wrote: > Natty is currently NOT showing the Hibernate option in the list of > shutdown choices. This is currently an experiment, but I thought it > might be worth discussing the pros and cons on these lists as well. > > So, thoughts, discussion, feedback, options, suggestions, rants, raves, > etc... ? I don't object to changing configurable defaults. The primary issue, IMO, is that it was removed from the kernel completely, so people do not have the option to use it even if they want to. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Rewriting update-maintainer
Hi, On Fri, Jan 28, 2011 at 12:07:38AM +0100, Benjamin Drung wrote: > BTW, why does the security team use it's own implementation instead of > update-maintainer from ubuntu-dev-tools? Our tool predated the one in ubuntu-dev-tools so we internal momentum issues. :) I'm actually making sure that they have as similar behavior as possible and then we'll switch to using u-d-t's version. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Rewriting update-maintainer
On Fri, Dec 17, 2010 at 06:56:18PM -0500, Andrew Starr-Bochicchio wrote: > On Fri, Dec 17, 2010 at 6:45 PM, Kees Cook wrote: > >> 3) Move the maintainer from the "Maintainer" to > >> "XSBC-Original-Maintainer" field and set "Ubuntu Developers > >> " as new Maintainer. > > > > This depends on the component target, so you need to look that up first > > (lines 33 through 42). > > My understanding is that "Ubuntu MOTU Developers > " and "Ubuntu Core Developers > " have been deprecated in favor > of using "Ubuntu Developers " > The Debian Maintainer Field Spec [1] seems to back this up. > > - Andrew Starr-Bochicchio > > [1] https://wiki.ubuntu.com/DebianMaintainerField Ah yeah, true enough. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Rewriting update-maintainer
Hi, On Fri, Dec 17, 2010 at 11:25:01PM +0100, Benjamin Drung wrote: > I am going to rewrite update-maintainer (it's in the ubuntu-dev-tools > package) to use python-debian. Looking at the current version, I am not > sure what this tool should exactly do. This is what the security team uses: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/build-tools/u-maint > 1) Check if "ubuntu" is in the Debian version. Go on to the next step if > yes, otherwise say "Not an Ubuntu package - Nothing to do." and exit. I took the option of examining the release name instead (line 23), since there are packages that are ubuntu-native and don't carry "ubuntu" in the version. > 2) Check if the Maintainer email address has a "@ubuntu.com" or > "@lists.ubuntu.com". Go on to the next step if no, otherwise say > "Already maintained by Ubuntu" and exit. This seems to catch most stuff: @([^\.]+\.)*(launchpad.net|ubuntu.com) (lines 26 through 31) > 3) Move the maintainer from the "Maintainer" to > "XSBC-Original-Maintainer" field and set "Ubuntu Developers > " as new Maintainer. This depends on the component target, so you need to look that up first (lines 33 through 42). > Did I oversee something? Is there a use case that is not covered? Any > other comments? If I receive no comments, I will JFDI [1] and release it > with the next upload of ubuntu-dev-tools. It needs to detect and update control.in files too (lines 18 through 21). -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /etc/init.d/* status .. what to do when transitioning to an upstart job?
Hi, On Wed, Dec 15, 2010 at 12:39:50PM -0800, Clint Byrum wrote: > One thought that Dustin Kirkland had was to ehnance the 'service' > command to look in a directory for shell snippets, something like > > /etc/service/status.d > > And if one exists for the job name, run it, otherwise just run the > upstart status and provide an LSB compatible return code. > > This would also allow for the post-start stanza to call the same code if > it is needed. > > Does anyone have strong thoughts on this? Given the service.d approach, > it would seem the correct course of action is to open a feature request > against sysvinit, document it in our upstart job writing best practices, > and to document this feature in the server guide. Why should this be external to upstart? This seems to me like a clearly missing feature in upstart itself. (i.e. a "status" stanza for services that need a non-passive check.) -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot report 2010-12-06
Hi, I managed to clear the following from the Sponsorship Queue today: - https://code.launchpad.net/~clint-fewbar/ubuntu/natty/php5/fix-mssql-segfault/+merge/42705 https://launchpad.net/bugs/611316 reviewed, updated DEP3 formatting, and changelog formatting. Approved review, merged bzr, built/tested, uploaded, thanks to ari-tczew and SpamapS. - https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/684874 reviewed, determined to actually need a sync, not a merge, thanks to ari-tczew, zul, and jdstrand. - https://bugs.launchpad.net/ubuntu/+source/xinetd/+bug/43574 https://code.launchpad.net/~smoser/ubuntu/natty/xinetd/bug43574/+merge/42637 Ubuntu will carry upstart delta, reviewed, built/tested, uploaded. - https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/486154 Reviewed, isn't ready for integration into Ubuntu. Needs to be examined by the Desktop team. - https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/686099 Reviewed, requested sync from jdstrand. - https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/685501 Reviewed, not a valid bug in packaging. - https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/681418 Reviewed, comments, flipped back to incomplete. - https://code.launchpad.net/~james-page/ubuntu/natty/xorg-docs/fix-682621/+merge/42214 Reviewed, marked for merge approval, actually merged. - https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/577239 Reviewed, seems like a potentially dangerous change based on feedback. - https://bugs.launchpad.net/nvidia-drivers-ubuntu/+bug/604525 Reviewed, looks good, was already tested, wrote changelog, merged, converted to cdbs patch, built, uploaded. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OSS emulation turned off in Maverick
Hi Ole, On Thu, Nov 18, 2010 at 11:10:36AM +0100, Ole Laursen wrote: > In any case, it turns out that there are some old programs that depend > on the OSS emulation. If you look through that bug report (and > associates), there are quite a few. I personally got a problem with > tvtime, the only working TV viewer for GNOME. In most situations, it is possible to use "padsp" to provide emulation support for individual programs that need the OSS interface. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
On Wed, Nov 17, 2010 at 03:38:53PM -0600, Dustin Kirkland wrote:
> Ubuntu has long maintained a "no open ports by default" policy.
https://wiki.ubuntu.com/SecurityTeam/Policies#No%20Open%20Ports
"Default installations of Ubuntu must have no listening network services
after initial install."
One point of these policies is to provide users with a clear set of
guarantees they can depend on when planning their use of Ubuntu.
> Several exceptions have been granted to this policy,
To clarify, it is actually a "class" of services that have a standing
exception: those that are required become a member of the network itself
("network infrastructure services"), so far: DHCP, IPv4LL, and mDNS.
> Let me be clear: I am NOT requesting that sort of an exception.
Then it will be the language of the first sentence that matters.
> 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.
Agreed, this makes perfect sense to me -- there is a large number of Ubuntu
Server users that immediately install openssh-server after the install is
finished.
> 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
I suspect this will be the core of the argument, and how it relates to
the definition of "default installation". I would argue that hitting
enter on all questions without reading them would result in a "default
installation". Taking this approach means highlighting "no" by default
would be policy-safe way to add this prompt.
> Please consider that the very definition of a "server" implies that
> the system is running a "service".
Well, I think this point is less clear-cut. There are people genuinely
interested in not running SSH. But, if it goes this way, then the argument
is centered around "installations of Ubuntu" for the definition of
"Ubuntu". Does that mean only "Desktop"? I would argue that it has meant
Desktop and Server, since security policy and features apply to both
equally.
> 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.
It was argued to me that "Ubuntu Enterprise Cloud" and "Ubuntu EC2 AMIs"
are not "default installations of Ubuntu", again centering around what
"Ubuntu" in the policy means. If this holds, then the language around
the policy should be clarified to handle these existing situations at the
same time as solving the "Server with SSH" situation.
-Kees
--
Kees Cook
Ubuntu Security Team
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: restricting dmesg
Hi Ted, On Tue, Nov 16, 2010 at 03:38:00PM -0600, Ted Gould wrote: > Well, I find it annoying, but a reasonable default. Perhaps we could > have a package "insecure-developer-workstation" that would set all of > these little debugging nicities back to "1" on startup? That way I > wouldn't have to keep up on all of them :) I use a similar package that does stuff like putting my window buttons back on the correct side. ;) I've got no problem with such a thing, but I want to work very hard to avoid it become part of any kind of regular documentation that says "first, install insecure-developer-workstation, then..." etc. No one should be blindly installing it. > I'd even have it install the first time you install a "-dev" package, > but that might be a little extreme. This was ruled out early on in the PTRACE discussions. It's just not really that straight-forward, unfortunately. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: restricting dmesg
On Tue, Nov 16, 2010 at 01:19:53PM -0800, Evan Broder wrote: > On Tue, Nov 16, 2010 at 1:16 PM, Kees Cook wrote: > > Not a peep that I'm aware of. I am assuming that the verbose errors out > > of strace, ltrace, and gdb were enough to address it, though maybe there > > won't be noise until the restriction is in an LTS version. > > I assume you're planning to add the same verbose errors to dmesg(1)? Yup, that's the plan. Seems like it worked before, so I'll happily repeat it. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: restricting dmesg
Hi Soren, On Tue, Nov 16, 2010 at 10:04:55PM +0100, Soren Hansen wrote: > On 16-11-2010 18:50, Kees Cook wrote: > > I figure we could add a useful error message to "dmesg" to provide > > education about the change, which would suggest using "sudo" or > > pointing people to the new /proc/sys/kernel/dmesg_restrict sysctl. > > Have we gotten any kind of feedback on the similar changes that were > made to strace? Not a peep that I'm aware of. I am assuming that the verbose errors out of strace, ltrace, and gdb were enough to address it, though maybe there won't be noise until the restriction is in an LTS version. -Kees (Though technically, the verbose error vanished briefly in gdb and that caused some confusion, but has since been fixed.) -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
restricting dmesg
Hi, So, now that it is possible[1] to restrict access to dmesg, I would like to make this restriction the default in Ubuntu. The information in dmesg can potentially leak kernel memory targets for local attackers. While there are certainly plenty of targets, this restriction will close a door on at least some of them. This will obviously mean changing documentation and a number of applications that use "dmesg" output. Luckily, they should all fall into the "debugging" category instead of the "regular use" category. (Specifically I'm thinking of Apport at the very least.) I figure we could add a useful error message to "dmesg" to provide education about the change, which would suggest using "sudo" or pointing people to the new /proc/sys/kernel/dmesg_restrict sysctl. Thoughts? -Kees [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eaf06b241b091357e72b76863ba16e89610d31bd -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: The default file descriptor limit (ulimit -n 1024) is too low
On Fri, Nov 05, 2010 at 01:46:23PM -0700, Steve Langasek wrote: > We should also fix it so pam_limits is able to grab the kernel default > limits from somewhere, instead of hard-coding these at compile time. I > think you suggested reading /proc/1/limits for this, though it's less than > ideal to be parsing this file to get that info. Well, the text there is unlikely to change, but it would be nice to have a more stable result. On the other hand, reading from /proc/1/limits means that per-container PAM would get the "right" limits, based on that container's init process. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: The default file descriptor limit (ulimit -n 1024) is too low
Hi Scott, On Fri, Nov 05, 2010 at 03:49:42AM -0700, Scott Ritchie wrote: > Upon investigation, it seems that there is support for a "soft" > (default) and a "hard" (apps-can-increase-themselves) limit. Would it > be ok if we raised the hard limit? I'm not hugely opposed to that; I am worried that people will just arbitrarily raise the limit on applications that can't handle it, though, but that at least requires some work. Does anyone seen a downside to raising the soft limit? As for how to do it, the limit comes from the kernel initially and is modified by Upstart and PAM, depending on configurations. I'm not 100% sure the best approach to take. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: brainstorming for UDS-N - Performance
On Mon, Oct 04, 2010 at 11:57:03PM +0800, John McCabe-Dansted wrote: > while ! wmctrl -R "$WINDOW_TITLE" # Attempt to raise window Nice! I hadn't seen wmctrl before. Yeah, this works as a great general start-up time measurement. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
