It's easy to critise but the reality is that to ship a high quality distro all packages promoted to main have to go through a thorough review process which takes time. So whilst it's not in main we can't have other pkgs in main depend on it. 1/2
-
-
Replying to @alex_murray @hanno and
It will likely get there soon, but the security team has limited resources and with 2018 being the year of a whole new class of vulns with seemingly no end in sight (aka spectre etc) everyone just has to be patient. 2/x
2 replies 0 retweets 7 likes -
Replying to @alex_murray @hanno and
I get it, but if you were saying "we didn't have resources to sandbox it", I would understand, but upstream wrote it and you're saying "we found resources to patch it out instead" - it's harder to grasp, no?
3 replies 1 retweet 37 likes -
No what I am saying is we didn't yet have resources to do the thorough review of bubblewrap so that we can satisfy ourselves that we can support it going forwards. This is days of work compared to minutes for a one line patch. So is not the same.
1 reply 0 retweets 0 likes -
Replying to @alex_murray @taviso and
bubblewrap is relatively new software doing some complicated things to set up sandboxes - if we just blindly promote it to main and then find out it has a vuln itself which we could have caught through code review beforehand that is not a good outcome for our users.
1 reply 0 retweets 1 like -
Replying to @alex_murray @hanno and
I don't follow how shipping "unreviewed" sandboxing would be a worse outcome for users than shipping no sandboxing. In your opinion, did you make the right call here? (i.e. you would make the same decision now: disable the sandboxing until you can review it)
1 reply 1 retweet 3 likes -
Until the review is done it's hard to make the call - bubblewrap is a new setuid executable and so deserves close review - and we have AppArmor already to sandbox the evince thumbnailer which reduces the need for bubblewrap in this case.
1 reply 0 retweets 2 likes -
Replying to @alex_murray @taviso and
When using your PoC from http://seclists.org/oss-sec/2018/q3/157 …: type=AVC msg=audit(1535072811.766:3555): apparmor="DENIED" operation="exec" profile="/usr/bin/evince-thumbnailer" name="/bin/dash" pid=14108 comm="evince-thumbnai" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
1 reply 0 retweets 1 like -
Replying to @alex_murray @hanno and
I know, what do you claim that proves? The Ubuntu AppArmor policy is ***very*** permissive. Please don't confuse matters by saying it's not vulnerable. It is vulnerable, it just needs to be exploited differently.
1 reply 0 retweets 1 like -
Replying to @taviso @alex_murray and
You're inches away from how Microsoft acted in the 90's, denying everything is exploitable unless an exploit is available, even if it's a trivial stack strcpy().
1 reply 0 retweets 1 like
I am not going to be thrilled if you make me write enough PostScript to send D-BUS messages, it is not a fun language to write. 
-
-
You misinterpret my response, I was simply trying to demonstrate how we have used AppArmor in this case. AppArmor is very useful but is certainly no silver bullet and is not always going to be the best fit. However we really are trying to make things more secure 1/x
1 reply 0 retweets 0 likes -
Replying to @alex_murray @taviso and
hence the fact we have the AppArmor policy in the first place. So please don't cast this response as something which it is not. We are all doing our best to try and get the most secure outcome but with different perspectives and with different constraints and responsibilities.
1 reply 0 retweets 1 like - 11 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.