<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 25, 2020 at 6:10 PM Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com">steve.langasek@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 25, 2020 at 02:04:51PM +1030, Alex Murray wrote:<br>
> > On Fri, Feb 21, 2020 at 02:04:37PM -0800, Kees Cook wrote:<br>
> >> On Thu, Feb 20, 2020 at 03:45:39AM +0000, Seth Arnold wrote:<br>
> >> > I'm worried that turning this flag on for the first time in an LTS release<br>
> >> > may be breaking too many expectations.<br>
<br>
> >> > Adapting applications may be too much effort; because I don't know what<br>
> >> > exactly apport is doing here it is hard to estimate how much effort it<br>
> >> > will take to adapt it. Possibly the user-launched apport instances need<br>
> >> > to create their own directory on launch. Possibly apport needs a<br>
> >> > more invasive redesign.<br>
> >> > [...]<br>
> >> > Source code searching is not practical. The combination of working<br>
> >> > with files in a world-writable sticky directory and not already using<br>
> >> > O_EXCL with O_CREAT is not feasible to search for.<br>
<br>
> >> FWIW, I think that the scope of the change is small enough (only in<br>
> >> world-writable stick directories) and dramatic enough (usually total<br>
> >> failure), that the risk is worth the benefit. Excepting the very few<br>
> >> special directories (like /var/crash, where the software using them<br>
> >> is likely enumerable), I would also argue that breaking stuff in<br>
> >> "standard" temp directories (like /tmp) that isn't using O_EXCL is<br>
> >> actually _desirable_, given that it is expressly risky to operate in<br>
> >> that condition.<br>
<br>
> >> And, I would suggest that doing this in an LTS is the right thing to do,<br>
> >> otherwise you wait 2 years before gaining this defense that would be<br>
> >> actively _disabled_ compared to all other distros with a modern version<br>
> >> of systemd. And if this is the first noticed problem, that seems to be a<br>
> >> reasonably good indication of how rare the case is of it creating "real"<br>
> >> problems.<br>
<br>
> > As an additional wrinkle, procps in focal-proposed is now setting<br>
> > fs.protected_regular=2 by default, overriding the systemd setting.  This<br>
> > hasn't made it out of proposed yet because the additional restriction broke<br>
> > the postgresql-common autopkgtest (fix for this is in progress):<br>
> > <a href="https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423</a><br>
<br>
> > Kees, it sounds like you were advocating for setting the level to<br>
> > fs.protected_regular=1, but NOT raising it to 2.  Should we back out this<br>
> > procps change for 20.04?<br>
<br>
> (I'll let Kees respond for himself but figured this was a good point to<br>
> reply)<br>
<br>
> From the Ubuntu Security team's view, it is not clear how much breakage<br>
> will result from setting this to 2 - setting protected_regular=1 is<br>
> already a good win and so far has seen little fallout that I know of<br>
> (Apport has already worked around this), but given how close we are to<br>
> FF I am a bit hesitant to mandate for this to be =2 (given we<br>
> already have one known failure as a result). From a security point of<br>
> view, =2 is a better default but this is not the only view that<br>
> matters.<br>
<br>
> So my preference would be to keep this at =2 for now but be confident<br>
> that we can back it out to =1 in the event that we suddenly discover a<br>
> bunch more issues in the near term.<br>
<br>
Thanks, it's easy enough to back out later (as long as someone actually<br>
raises a flag when things break!), so I'm ok with that.<br>
<br>
Since postgresql-common's tests have now been fixed for compatibility with<br>
=2, the procps with this new behavior will be unblocked and should reach the<br>
focal release today or tomorrow.<br></blockquote><div> </div><div>I think it won't migrate as-is.</div><div>Since this was out-of order compared to Debian there are a few no-change-rebuilds needed.</div><div>Update_output suggests we are stuck on the rev-deps to the old lib version:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)"><br></span></span></div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">$ reverse-depends -r focal libprocps7
</span><br>Reverse-Depends
<br>===============
<br>* apitrace [amd64 arm64 armhf ppc64el s390x]
<br>* cpu-x [amd64]
<br>* deepin-screen-recorder [amd64 arm64 armhf ppc64el s390x]
<br>* intel-gpu-tools [amd64 i386]
<br>* libprocps-dev
<br>* procps
<br>* veyon-plugins [amd64 arm64 armhf ppc64el s390x]<br></span></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Steve Langasek                   Give me a lever long enough and a Free OS<br>
Debian Developer                   to set it on, and I can move the world.<br>
Ubuntu Developer                                   <a href="https://www.debian.org/" rel="noreferrer" target="_blank">https://www.debian.org/</a><br>
<a href="mailto:slangasek@ubuntu.com" target="_blank">slangasek@ubuntu.com</a>                                     <a href="mailto:vorlon@debian.org" target="_blank">vorlon@debian.org</a><br>
-- <br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Christian Ehrhardt<br>Staff Engineer, Ubuntu Server<br>Canonical Ltd</div></div>