Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hi, În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris: And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact. Kernel debugging options on the other side seem to have a much bigger impact. It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. The facts will remain though: * the kernel will still be everything and the kitchen sink. * no provable performance enhancement so far. * security measures will get back at square 1. ¹ http://www.phoronix.com/scan.php?page=articleitem=fedora_debug_selinux ² https://dl.dropboxusercontent.com/u/29107946/Assessing-the-Performance-Impact-of-the-Linux-Kernel-Audit-Trail.pdf As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here. -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 11:54 AM, Arthur Țițeică art...@psw.ro wrote: Hi, În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris: And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact. Kernel debugging options on the other side seem to have a much bigger impact. It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. Exactly my thoughts about this thread. http://i.imgur.com/nfFuu.jpg I'm very much for cleaning up the kernel config from things that factually are useless. Thanks for reading up everyone and keep trying to not step on each other's toes. cheers! mar77i
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 28-03-2014 10:54, Arthur Țițeică wrote: It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. Of the people that have pkgstats installed, almost no one is using any of the security features, selinux and apparmor don't even register in the stats [1], if they are not being used I don't see how removing/disabling them makes for a less secure system. Using selinux/apparmor/tomoyo requires comprehensive well written rules, which no one is willing to maintain because it is a huge and hard job. Things will subtly break after a while if rules are not rechecked with every package update, it's not a matter of if but when will they break, specially with arch that keeps close to the latest upstream releases. People have complained that audit pollutes their logs and apparently it is broken for containers and has to be disabled it with audit=0. Less code means less bugs and a smaller attack surface, and I suppose less of a burden for the one(s) actually maintaining the kernel package. If no one comes forward and says: please don't remove features a b and c because I'm actually making use of them in a production system, then I suppose the features will be removed. [1] https://www.archlinux.de/?page=PackageStatistics -- Mauro Santos
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 28/03/14 06:54 AM, Arthur Țițeică wrote: Hi, În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris: And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact. Kernel debugging options on the other side seem to have a much bigger impact. It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. These 'security measures' do nothing but provide hooks for malware to latch onto. Audit and LSM are a rootkit author's wet dream. It's strictly a security *improvement* to have them disabled if there's no userspace support as it just increases the kernel surface area and provides more useful post-exploitation tools. Claiming that we will have 'security measures disabled' is just hyperbole when Arch Linux is shipping with protected symlinks, hardlinks, ptrace_scope=1 and stack smashing protection. It certainly doesn't disable namespaces and seccomp-bpf. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it. It's the same kind of hogwash as Windows security tokens, where it looks great from a theoretical point of view but is far too complex to actually use correctly. The Chromium sandbox is broken over and over on Windows because this complex token design simply doesn't work. On Linux, it uses a simple chroot, namespaces and seccomp whitelist. It doesn't ever get in the way of users, and it's easy for any developer to understand. If a story ran on the Guardian tomorrow showing that the NSA open-sourced SELinux to set back the development of MAC by *years* by sending people down the wrong path, I would not be the least bit surprised. :P The facts will remain though: * the kernel will still be everything and the kitchen sink. * no provable performance enhancement so far. * security measures will get back at square 1. Neither AppArmor or SELinux is provided in the official repositories, so enabling these in the kernel only adds attack surface. I doubt that using AUR packages provided by a different group of maintainers every week is going to improve anyone's security. If someone wants to attack Arch users, their easiest shot at it is taking over a somewhat popular AUR package (like apparmor) and sticking some subtly malicious code in the source or install file. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Must use nomodeset to enable boot [SOLVED]
On 16 Mar 2014, Anthony Campbell wrote: I have a Thinkpad T42 which has been happily running Arch for many months. Its video is AMD/ATI. After a recent upgrade I started getting the dreaded blank page on boot. Googling showed a lot of discussion of this on various distros including Arch. The only solution seems to be to set nomodeset, which works, but it appears to be deprecated. It's supposed to prevent some opensource drivers from working, although so far mine does. Any comments or advice about this please? There's been a lot of dicussion of this on the kernel-hardware forum, with lots of proffered solutions. Nomodeset stops the radeon module from being loaded. But at least for me, the problem has gone away today after an upgrade of systemd to 212-1. -- Anthony Campbell - a...@acampbell.org.uk http://www.acupuncturecourse.org.uk http://www.smashwords.com/profile.view/acampbell https://itunes.apple.com/ca/artist/anthony-campbell/id73235412
[arch-general] svntogit stuck
In case some of the people responsible for it are reading this: svn2git is stuck for 2 days without any changes although the packages are being upgraded. I can't even examine changes for packages through al.o/packages anymore. -- Note: My last name is not Krejzi.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 12:54:44PM +0200, Arthur Țițeică wrote: It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. The facts will remain though: * the kernel will still be everything and the kitchen sink. * no provable performance enhancement so far. * security measures will get back at square 1. There seems to be a general, significant misunderstanding floating around this thread. The security features in question are not passive; their mere existence within the binary kernel does not improve security. They are modules that allow users to fine-tune certain security features through the kernel using third-party tools, features that are almost exclusively useful for server administration (since, if you're the only one with access to your single-user machine, they won't tell you anything you can't already see without them). If you've never installed and configured the SELinux/AppArmor/Tomoyo userspace packages, you've never had the security they purport to provide. Hence the point of removing their modules from the kernel isn't performance; it's that *no one uses them,* and they clutter up the kernel configuration for no good reason at all, making it more tedious to maintain and just a bit more annoying to configure for individual users for absolutely no benefit. -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
I'll answer random things I read in the thread. First, I don't think the lightweight part of the philosophy is about using stock packages, as that's implied in the KISS philosophy, you don't need to stress it any more than that. The same KISS philosophy says one should try to avoid complexity whenever possible. Lastly, any decision taken will hurt someone. You keep the features? Then the ones who want the lighter, simpler kernel will suffer from a less tested build. You drop them? Servers (and any other user, whatever reason) will suffer from the same. However, the code paths they use exclusively are really not tested more by being in the main repos. Why? Because the ones using it, use it through AUR packages. If the feature is unusable without AUR packages, then they effectively get testing only from the ones who install AUR packages. Sure, they have some extra guarantee that drivers are not broken (except if they behave differently under AppArmor, SELinux, etc, do they?), but they don't have any testing on the actual features that are being included only because they use them. Needless to say, I'm all in favor of using minimal builds by default.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 2:40 PM, Bigby James bigby.ja...@crepcran.com wrote: On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote: I'm very much for cleaning up the kernel config from things that factually are useless. Factually useless is not a subjective standard by which to measure things. If I fully agree. Neither is common sense, obviously. you don't personally configure the features in question by installing third-party userspace packages then they are, in fact, useless to you. If you Well, they came in when people argued in favor of them. [0] don't contribute code to the kernel, the kernel debugging features (which eat up a lot of build time) are almost certainly, in fact, useless to you. Such is the I guess we all agree about the debugging features. case for everything found in the kernel: Someone, somewhere will find it useful, and that's a fact. Whether the majority of Arch users find it useful, and it therefore should be maintained by a limited staff with limited resources, is what's in question here. If a justifiable amount of effort saves a significant amount of time and energy for the few people who use it, I'm in favor of the security features being there so I have them at my disposal in case I would decide to experiment with them one day too. The hurdle to consider such features is higher if they aren't in the official kernel, as building a kernel takes time and caution. What will actually happen is fully that person's decision who will or will not implement change. And no, I'm not aware of any decisions around Arch needed any kind of majority. Good day. mar77i [0] https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.html
Re: [arch-general] per error
Looks like you want to install perl-html-parser. On Fri, 28 Mar 2014, message wrote: Readers, 'get_iplayer' is a program to extract media from BBC F(/tr)ash streams. After installation of the program, obtained the following error: Can't locate HTML/Entities.pm in @INC (you may need to install the HTML::Entities module) (@INC contains: /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at ./getiplayer line 58. BEGIN failed--compilation aborted at ./getiplayer line 58. line 58: use HTML::Entities; Tried re-installation of perl (518222 already installed) and failed. Any suggestions to solve please? -- Scott Lawrence Linux baidar 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 03:05:25PM +0100, Martti Kühne wrote: Well, they came in when people argued in favor of them. [0] [0] https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.html That entire thread regards the userspace packages and the kludge of a policy that are in the AUR, and about the fact that they weren't even being properly maintained. It doesn't refer to the in-kernel modules/code. If a justifiable amount of effort saves a significant amount of time and energy for the few people who use it, I'm in favor of the security features being there so I have them at my disposal in case I would decide to experiment with them one day too. So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that one day is a year from now? Two years? And what if your time spent experimenting leads you to conclude that these things are factually useless to you? What then of the effort the devs put into it? As I mentioned above regarding the thread you linked to, the person previously maintaining the userspace packages couldn't keep them up-to-date. The Arch devs don't maintain Arch for a living; their lives are no less complicated than the rest of ours. I'll gladly admit that the reason I'm all for eliminating these things is because I have no use for them myself, and removing them when I build my own kernel makes configuration slightly more inconvenient than it would be if they weren't there in the first place, and since no one seems to really use them regularly, there's no real sense in keeping them. But ultimately, if more people did use these things than didn't, and the devs deemed it worth their time to maintain them, then my own concerns are moot. They keep the OS I love stable and versatile; if deciding either keeping something I don't care for or eliminating something I find useful makes it easier for them to handle Arch development and maintainance, that counts for more than my convenience. -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@crepcran.com wrote: So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that one day is a year from now? Two years? And what if your time spent experimenting leads you to conclude that these things are factually useless to you? What then of the effort the devs put into it? How did it happen that we're arguing about someone else's effort? Both of us are not trying to tell anyone to do anything, because people know that if they do something they do something and if they don't they don't. Stop standing in the way. cheers! mar77i
[arch-general] per error
Readers, 'get_iplayer' is a program to extract media from BBC F(/tr)ash streams. After installation of the program, obtained the following error: Can't locate HTML/Entities.pm in @INC (you may need to install the HTML::Entities module) (@INC contains: /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at ./getiplayer line 58. BEGIN failed--compilation aborted at ./getiplayer line 58. line 58: use HTML::Entities; Tried re-installation of perl (518222 already installed) and failed. Any suggestions to solve please?
[arch-general] Java 8
I'm just wondering what the plan is, if any, for getting java 8 packages into arch? -- Caleb Cushing http://xenoterracide.com Calendar: https://www.google.com/calendar/embed?src=xenoterracide%40gmail.comctz=America/Chicago
Re: [arch-general] svntogit stuck
Am 28.03.2014 14:29, schrieb Armin K.: In case some of the people responsible for it are reading this: svn2git is stuck for 2 days without any changes although the packages are being upgraded. I can't even examine changes for packages through al.o/packages anymore. It seems the script produced an error, aborted and a lock file stuck around. I removed the lock in the hopes that it will update soon. Thanks fdor the hint. signature.asc Description: OpenPGP digital signature
Re: [arch-general] What's with F# and mono?
Great, there is hope then :) Do you happen to remember where you found that add-on for MonoDevelop? I can't seem to find one that can be downloaded AND plugged into MD. I'm pretty sure that when I first set it up, I installed it from the Add-in manager -- Language Bindings, but it's no longer there. I did find this [1], but the compile fails when I try it. Let me know if you get it working. [1] https://github.com/fsharp/fsharpbinding -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N https://github.com/headmastersquall
[arch-general] package ncurses lacks c++ support
In core/ncurses, we have c++ wrapper header files like cursesw.h, but the corresponding library was not included. Actually, gnu ncurses itself only builds a static libncurses++.a. Is there any need to do some extra work to add a libncurses++.so to the package?
Re: [arch-general] per error
Readers, 'get_iplayer' is a program to extract media from BBC F(/tr)ash streams. After installation of the program, obtained the following error: Can't locate HTML/Entities.pm in @INC (you may need to install the HTML::Entities module) (@INC contains: /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at ./getiplayer line 58. BEGIN failed--compilation aborted at ./getiplayer line 58. line 58: use HTML::Entities; Tried re-installation of perl (518222 already installed) and failed. Any suggestions to solve please? Do you have the following dependencies installed? perl-html-parser perl-http-cookies perl-libwww perl-net-http perl-www-mechanize I'm pretty sure it's the same error I had before I installed perl-libwww. --timttmy
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote: I'm very much for cleaning up the kernel config from things that factually are useless. Factually useless is not a subjective standard by which to measure things. If you don't personally configure the features in question by installing third-party userspace packages then they are, in fact, useless to you. If you don't contribute code to the kernel, the kernel debugging features (which eat up a lot of build time) are almost certainly, in fact, useless to you. Such is the case for everything found in the kernel: Someone, somewhere will find it useful, and that's a fact. Whether the majority of Arch users find it useful, and it therefore should be maintained by a limited staff with limited resources, is what's in question here. -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 03/28/2014 09:12 AM, Daniel Micay wrote: ... Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it. I think the above is a tad misleading. While we don't yet have user space tools - which was I believe a key, if not critical, point Thomas was making - selinux is very useful and adds a strong security layer. The kernel code is well audited and well tested in real world too. Just not by us Arch folks - at least today - without the user space and policy support in core. I cannot speak for AppArmor, but I do recall when the big debate to include it in mainline or not was going on, that Linus was a big proponent of using both together. Hence, today both are there. And, it's not only for servers but for laptops as well. In fact newer versions of Android phones/tablets use selinux enabled in enforcing mode. So with the right user space policies (redhat has some good base configs here) selinux could be a strong add for Arch linux in the future - maybe. The discussion here, I thought, was whether having it in the stock Arch kernel offers any value to the community today. As Thomas said - it's pretty easy to build a custom kernel via abs if you want to work on user space policy etc. I would actually like to see Arch have selinux support - it would make us stronger - but we just don't have the tools and policies today. gene
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 28.03.2014 17:11, schrieb Martti Kühne: On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@crepcran.com wrote: So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that one day is a year from now? Two years? And what if your time spent experimenting leads you to conclude that these things are factually useless to you? What then of the effort the devs put into it? How did it happen that we're arguing about someone else's effort? Both of us are not trying to tell anyone to do anything, because people know that if they do something they do something and if they don't they don't. Stop standing in the way. You can actually stop arguing about the SELinux issue entirely, since I think I heard all the basic arguments on both sides (if you have something _really_ new to add though, feel free to do so). I'll make up my mind about it and decide how we proceed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] svntogit stuck
packages.git looks fine to me now, but community.git is still stuck.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hi, În ziua de Vineri 28 Martie 2014, la 12:54:44, Arthur Țițeică a scris: As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here. I managed to finish testing. As said above I picked up this test because it was the only one standing out with a great difference between the stock kernel and a selinux/audit configured kernel. It's also a very easy test to perform. The raw spreadsheet data and the conditions for the test may be found at ¹. I would really appreciate some help creating some nice graphs with this data. My conclusions so far: there's no difference between the stock -ARCH kernel and my -NOLSM build in which I disabled all LSMs (and hence audit). Note: the final test with 50 files for the rotational disk isn't finished yet because... really... I shaved twice during the HDD tests. A side note regarding these tests: SSDs act according to their fame and HDDs are as misleading as a daily horoscope. I do plan to also test a no-debug but LSM enabled kernel even if it's just for the sake of statistics. ¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Java 8
On 28 March 2014 18:30, Caleb Cushing xenoterrac...@gmail.com wrote: I'm just wondering what the plan is, if any, for getting java 8 packages into arch? -- Caleb Cushing http://xenoterracide.com Calendar: https://www.google.com/calendar/embed?src=xenoterracide%40gmail.comctz=America/Chicago Hello, There is no official Java 8 package in Arch Linux because the OpenJDK we provide uses the IcedTea [0] but unfortunately IcedTea has no stable version available **yet** for Java 8. More details about IcedTea roadmap here [1]. So the plan (for me at least) is to wait for IcedTea 3.0 that will support Java 8. Shipping a vanilla OpenJDK8 into extra (possibly from the binaries provided by Oracle) could be an option in the meantime. [0] http://icedtea.classpath.org/wiki/Main_Page [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026727.html -- Guillaume
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 28/03/14 02:36 PM, Genes Lists wrote: On 03/28/2014 09:12 AM, Daniel Micay wrote: ... Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it. I think the above is a tad misleading. While we don't yet have user space tools - which was I believe a key, if not critical, point Thomas was making - selinux is very useful and adds a strong security layer. The kernel code is well audited and well tested in real world too. Just not by us Arch folks - at least today - without the user space and policy support in core. Well I don't really think it's useful, There are much simpler alternatives, like isolating services and applications in containers (chroot, namespaces, seccomp-bpf) and using AppArmor + the protected symlink/hardlink switches (on by default) to pick up the slack when you're not willing to put in much work. Simplicity is really important in this domain, because you need to be able to audit a full policy, and that's very difficult when data is spread out through the filesystem. A mistake in the metadata for a single file can break the isolation. I don't really believe SELinux has a purpose beyond satisfying overly complex security policies created by bureaucracy. I can't see Arch ever being used in these situations. I cannot speak for AppArmor, but I do recall when the big debate to include it in mainline or not was going on, that Linus was a big proponent of using both together. Hence, today both are there. AppArmor was not incredibly useful before Yama came along with the protected symlink/hardlink features (now part of the core kernel). It's useful now, but I still think you're better off using containers in most cases. As far as I know, Linus is no fan of LSM and has done everything he can to keep this stuff out of the core kernel. There are cases where I think this was a mistake, like the `ptrace_scope` option requiring the stub Yama LSM. And, it's not only for servers but for laptops as well. In fact newer versions of Android phones/tablets use selinux enabled in enforcing mode. So with the right user space policies (redhat has some good base configs here) selinux could be a strong add for Arch linux in the future - maybe. Android is not exactly a shining example of a security. SELinux hasn't really changed anything other than adding a buzzword. The shared sdcard data can still be read/written by any application (no permissions or attributes there at all), and nothing else really changed. It might add some defence in depth, but they could have gotten this by leveraging namespaces/chroots or AppArmor too. signature.asc Description: OpenPGP digital signature
