Fedora opens up to bundling
Fedora opens up to bundling
Posted Oct 14, 2015 17:20 UTC (Wed) by tpo (subscriber, #25713)In reply to: Fedora opens up to bundling by Cyberax
Parent article: Fedora opens up to bundling
> Security issues? Who cares, just update all the libraries once in a while. Utilize OS-level sandboxing and exploit protection to help mitigate the usual exploits.
The perspective from the other side - the user side - might be different.
As a sysadmin I see software that I need to maintain that:
* bundles half the world
* comes with it's own init system
* logs into /usr/share/software
* fails to rotate its logs
* doesn't have the ability to log to rsyslog
* has configuration at completely random places, sometimes indistinguishable from binary files
* fails to upgrade properly
* is 32bit only
It makes me vomit. Every piece of such software lives in it's own special snowflake world. Consistent config management is impossible. Consistent version control is impossible. Consistent log management is impossible. Consistent backup procedures are impossible. Updating the environment is extremely brittle and risky. Migrating the software to a new platform is hit or miss. Security it a complete unknown. Which directly limits the use of such software to amateur environments, or you need guarantees that the vendor will not give you. The cost of completely ignoring best practice (== distro standards) is very high for the sysadmin.
As a end user I see software that bundles the whole world. Each piece of shit bundles its own Java. Do taxes for 2014? 100 GB, there you go. And 2015? Another 150 GB. You moved to a different town? And so on. And you need to back that crap up as well.
And there are appliances and hardware devices. The device has some bug? Bad luck. Your environment evolves and the device should be adapted accordingly? Bad luck! You know it's based on some Linux or library with known exploits? Bad luck!! The device is running out of some resources under your operating conditions? Bad luck!!!!
Then there's the ilk of web apps. Each comming with it's own ruby, gems, php, rails version, java script and ruby libraries, hard dependencies on some version of xml headers and mysql headers and so on. Never mind those are write once and forget because no one will ever care to update or maintain that crap. It's the router firmware plague of web apps. If I'd had to crack some company then I'd start by having a look at their "content management system".
Don't misunderstand me - I do believe that it is possible to maintain a bundle containing the full software stack of some application well - Chrome might be an example. On the other hand it is also possible to maintain a package for the top half dozen of popular distros and platforms well. Both of these approaches come with non-negligible costs.
But it's arguably far easier to bundle together some random mix of git checkouts, data and config files and libraries that just happened to work at the moment they were shipped and that was that. In my experience if some software has it's own non-distro-provided installer then it'll be gross with a very high proability.
So if you are preaching to the "elite" software developers backed by honest companies with a horizon of a dozen or more years to maintain their software and serious documentation and integration surfaces, then all the power to you.
I doubt however yours is a good advice to give to to Joëlle developer from Standard company - see my experience above.
Posted Oct 14, 2015 18:06 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
>* comes with it's own init system
>* logs into /usr/share/software
>* doesn't have the ability to log to rsyslog
>* has configuration at completely random places, sometimes indistinguishable from binary files
> It makes me vomit. Every piece of such software lives in it's own special snowflake world.
Posted Oct 15, 2015 7:29 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (21 responses)
Of course it does. The root reason for bundling is that a developer wants to take as many shortcuts as possible and avoid thinking at anything but his ego-boosting code. That's why a bundled environment is crap crap and more obsolete unsupported unsecured undocumented hastily patched crap. It's only there to allow the precious developer code to run, and any problem in the bundled substrate is "someone else's" problem.
If the developper could he would image his ide and ask users to push the run button there.
Log management and use of common system services is 200% in the "avoid work" zone.
Posted Oct 15, 2015 7:53 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
As long as she gets users, why not.
"The customer is always right" - and the thief impersonating him even more.
Posted Oct 15, 2015 12:01 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
Posted Oct 15, 2015 8:01 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
Posted Oct 15, 2015 18:49 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (17 responses)
Posted Oct 15, 2015 21:00 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
Just sandbox it to make sure it can't harm other apps.
Posted Oct 17, 2015 18:34 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (15 responses)
Back in 2005, Raymond Chen wrote about the issues with putting old programs into a VM, so you don't have to maintain proper backwards compatibility. Short form: it doesn't really work that well. The specific problems encountered back then might be different from those of the new-fangled container sandbox approaches you see today, but the common theme is the same. Users expect their programs to interoperate.
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/05/47...
And no, asking the user at every step of the way is not a solution.
Posted Oct 18, 2015 2:39 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
It's also possible to do the inverse - a browser can set up a protected storage for sensitive data which is not accessible to normal processes (it also automatically disables debugging for the sensitive process).
This is a far better approach than playing whack-a-mole with bugs where one single bug in an "Exploding Kittens" game might be enough to get access to ALL your files.
Posted Oct 20, 2015 22:15 UTC (Tue)
by javispedro (guest, #83660)
[Link] (13 responses)
That doesn't even start to cover all the holes that should be poked. What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.
Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...
There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.
And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.
> This is a far better approach than playing whack-a-mole with bugs where one single bug in an "Exploding Kittens" game might be enough to get access to ALL your files.
But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Being an idealist, I still think that a system that doesn't encourage huge monster applications (and thus keeps bug numbers at manageable levels) is a much better approach.
Posted Oct 20, 2015 23:29 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.
> Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...
> But sandboxing as it is done now usually involves making programs larger
> (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Posted Oct 22, 2015 9:54 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
> Nope. It'll only get access to that presentation and perhaps some recent files.
Cyberax, sometimes you need to "engage brain before opening mouth".
"One bug" == "pwned", and who knows what damage is done :-( If it has LO's permissions, then it can access all of LO's files. (Which for most users, is pretty much everything.)
(Incidentally, LO is not a monolithic blob. Although I'll admit it often feels like it ...)
Cheers,
Posted Oct 22, 2015 14:32 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
On Linux, a compromised document can slurp browser's history and secret storage and send it to nice folks in Nigeria.
Now, which model do you trust more?
Posted Oct 22, 2015 15:15 UTC (Thu)
by javispedro (guest, #83660)
[Link] (9 responses)
i.e. punch specific holes in the sandbox. Hard to do when there are gazillions of possible usecases, and most of them we don't even envision today.
> Command-line apps are somewhat special.
And this I disagree with. Specially in the context of a distro's packaging, command-line apps are _the norm_.
> Uhm? What?
Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.
Otherwise, something as trivial as copying and pasting a plot from the spreadsheet program to the word processing program using anything more advanced (i.e. vector, linking, etc.) than a shared .png file becomes a nightmare.
An example of this is iOS.
> Nope. It'll only get access to that presentation and perhaps some recent files.
Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files, esp. all of the text documents, the spreadsheets with financial data, presentations, drawings, the mailing list with all of your patients which you used once with your word processor, and the list of all words you've even written on any document so far (which obviously are only kept for "training purposes"), etc.
Posted Oct 22, 2015 22:52 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
> Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.
> Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files
Please, educate yourself about the state of the art, at least.
Posted Oct 25, 2015 14:22 UTC (Sun)
by mp (subscriber, #5615)
[Link] (1 responses)
Through complex LSMs that NOBODY understands? Oh well.
Posted Oct 26, 2015 5:57 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
To be fair, in Mac OS X command line utilities invoked through exec() from sandboxed apps do have read-only access to Unix system directories, but they don't have access to users' directories.
Posted Oct 26, 2015 15:53 UTC (Mon)
by javispedro (guest, #83660)
[Link] (5 responses)
That's a _huge_ thing to say. How do you even know 6 months by now there won't be a usecase that needs direct access from your word processor to your phone?
Hell, I'm sure _I_ wouldn't bet against it!
> And so? App Store model works for most users.
NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.
> Sandboxing command-line utilities is also possible
> No, that's incorrect. Mac OS does not allow programs to store authorizations forever.
So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?
> Please, educate yourself about the state of the art, at least.
Please turn your brain on a bit before replying, as you've been told above.
Posted Oct 26, 2015 17:29 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.
> So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?
Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.
> Please turn your brain on a bit before replying, as you've been told above.
Posted Oct 26, 2015 19:55 UTC (Mon)
by javispedro (guest, #83660)
[Link] (3 responses)
> I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?
>> There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.
> You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.
> Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.
Posted Oct 26, 2015 20:16 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.
> Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria.
Also, AppStore model allows vendors to quickly make and QA a patch for a security issue. With distros you have to go through maintainers and slow release process. Then you have to do QA for multiple distro versions.
It's pretty clear which security model is more advantageous.
> Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.
Posted Oct 27, 2015 7:20 UTC (Tue)
by javispedro (guest, #83660)
[Link] (1 responses)
But you need _operating system_ updates in order to punch these new holes in the sandbox, not software vendor actions. And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux). Unless you're thinking final software developers will ship the list of sandbox holes they need, but while this is a very interesting approach for a user trusted catalog of software (e.g. distro repository) it does not seem valid for a general "app store" model.
Remember that I'm saying the Apple sandbox model does not even provide half of the holes required for even a mere office suite to work well. The only such program that I currently known working under the sandbox is NeoOffice, and they do trickery such as showing up an OSX open dialog pointing at the file it wants to read every time it wants to read some random file. They also disable all extensions and is generally a pain to use. And this is most probably an example of a program that in theory seems easy to sandbox.
> Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.
Sorry but we're going circles about this:
And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.
I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.
> Linux-style dependency management clearly doesn't work well.
Posted Oct 27, 2015 8:02 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux).
> And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.
> I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.
So let's actually think about the threat model. Suppose I want to steal users' credit card information.
2) I have an exploit for LibreOffice itself. With a naïve distro model I simply need to hack LibreOffice and I instantly get access to browser's history with all the juicy CC info. With the sandboxed code I have to try and infect other documents, hoping that a user eventually opens a document with CC info.
So it appears that distro model provides no advantage here. Now, there might be a question of update speed. A distro might be able to update a shared library faster than a vendor can go through a full formal QA process. And that actually might be a disadvantage.
Fedora opens up to bundling
Yawn.
Inevitable, since each distro has its own mess. Systemd fixed this, but it's not yet everywhere.
>* fails to rotate its logs
Inexcusable but has nothing to do with bundling.
Nothing to do with bundling.
>* fails to upgrade properly
>* is 32bit only
Nothing to do with bundling.
So why do you insist then that your special snowflake of a distro should be supported? It's RHEL4 time for you.
Fedora opens up to bundling
>>* fails to rotate its logs
>Inexcusable but has nothing to do with bundling.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
You got it in one. But you're saying it like it's a bad thing. Why?
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Apple does this just fine with their sandboxing for AppStore applications. Basically, "Open File" action allows an application to access user-specified files.
Fedora opens up to bundling
Fedora opens up to bundling
It covers most.
If your spellchecker is specific to AbiWord and Libreoffice - you can explicitly whitelist it in each application. Otherwise, a user must grant your application (somewhat mislabeled) "Accessibility" permissions.
Command-line apps are somewhat special. They can be sandboxed, but nobody really cares about them.
Uhm? What?
Nope. It'll only get access to that presentation and perhaps some recent files.
Fedora opens up to bundling
Wol
Fedora opens up to bundling
That's not true for sandboxed apps on Mac OS X. A document file with an embedded exploit will probably not be able to access even the recently opened documents. It definitely won't be able to modify the LO executable files or even _read_ other user's files.
Fedora opens up to bundling
Fedora opens up to bundling
Not really. Most of the integration points for regular desktop use are known by now. Anything more advanced will require special-level access, but even developer desktops these days are pretty much vanilla.
And so? App Store model works for most users. Sandboxing command-line utilities is also possible - through SELinux or similar approaches.
No, that's incorrect. Mac OS does not allow programs to store authorizations forever.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
And precisely from a decade of SELinux experiences I know how stupid most sandboxing is, and how hard it is to actually make it usable.
Fedora opens up to bundling
> Hell, I'm sure _I_ wouldn't bet against it!
Operating systems are not set in stone. If there's a demand then new integration points are likely to be added. That is happening all the time both with iOS and Android.
I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?
You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.
Should I repeat my advice?
Fedora opens up to bundling
To sum it up: not only there's a huge amount of holes that need to be punched, but you need to keep punching brand new holes "all the time".
>> And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.
Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.
Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria. Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.
Fedora opens up to bundling
And that's fine. Vendors release new versions of applications all the time.
You assume that you can infiltrate through configuration. It's much less likely, especially if good config framework is used.
Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.
So what's your proposal? Linux-style dependency management clearly doesn't work well.
Fedora opens up to bundling
>> But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Note that sandboxing is independent of dependency management.
Fedora opens up to bundling
Yes. But currently application vendors are not just at the mercy of the OS, but at the mercy of many packagers! It's even worse - what if your app depends on a feature of a package with asshole maintainer?
Quite unlikely. New APIs rarely affect the old APIs.
Viruses these days exist to actually earn money for their developers. Botnetting and browser history (including CC information) are the easiest target, while documents are almost always useless.
So basically you're saying: "I believe in magic and unicorns". No packaging system can make a complicated office suite a "small" program. It might remove a bunch of peripheral dependencies, but nothing else.
1) If I have an exploit for a widely used library like zlib or libpng then I probably wouldn't want to bother exploiting LibreOffice, never mind trying to exploit a sandboxed LibreOffice.