(forw) [conspire] Huge Nov. 5th Washington Post article on Linux security

(Original at http://linuxmafia.com/pipermail/conspire/2015-November/008218.html .) Hey, Sam Varghese, would you like a posting on what you got wrong in your article 'Linux security: circling the wagons'? It's a good piece, with only minimal sensationalism, excusable on grounds of a need for adding some zing. But there are things you kind of blew and mischaracterised, including utterly missing the point and tenor of Jon Corbet's reference to the 1999 Mindcraft affair. You're still among my favourites, though, my good man! ----- Forwarded message from Rick Moen <rick@linuxmafia.com> ----- Date: Mon, 9 Nov 2015 18:36:21 -0800 From: Rick Moen <rick@linuxmafia.com> To: conspire@linuxmafia.com Subject: [conspire] Huge Nov. 5th Washington Post article on Linux security Organization: If you lived here, you'd be $HOME already. Four days ago, one Craig Timberg published a very, very long article in the _Washington Post_: 'The Kernel of the Argument: Fast, flexible, and free, Linux is taking over the online world. But there is growing unease about security weaknesses.' http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-k... It's gotten a lot of notice, including quite a bit of deserved sarcasm, starting with the awkward reference to 'kernel' and photo of Torvalds at the top, even though the piece is almost entirely _not_ about the Linux kernel. The blunder is obvious and an easy target, but quite possibly not even mostly of Timberg's making: At most publications, article authors have little or no input into the choice of title and presentation. OTOH, Timberg _is_ guilty throughout the piece of being aware of 'Linux' as a kernel differing from 'Linux' as hundreds of different suites (distros) of the kernel plus thousands of userspace codebases, many of the latter cross-platform, and nonetheless blurring the distinction. This is important because if, say, you speak of a flaw on BIND9 or Apache httpd as a problem with 'Linux', you are being either clueless or dishonest or both unless you call it a problem with 'Linux, Windows, MacOS, and everywhere else these programs run'. Also, blaming the kernel for failing to prevent the flaws in badly written userspace applications is a serious failure of perspective unless carefully explained. To jump ahead for a moment, yes, this is one of the many things Timberg screws up -- especially the latter bit. Herewith, a brief effort to sort out the wheat from the chaff, and comment on both. (I don't promise I won't cut short and bail, or at least switch to doing this in installments, for reasons that will be apparent if you note the length and discursiveness of Timberg's piece.) critics warn that [Linux] has security weaknesses that could be fixed but haven't been So nu? This is true of every codebase ever written. Is Timberg ghostwriting some insider or insiders' peeve? Next paragraph: Worse, as Internet security has surged as a subject of international concern, Torvalds has engaged in an occasionally profane standoff with experts on the subject. Torvalds has had occasionally profane standoffs with just about everyone occasionally, but in this case I'm guessing that the people Timberg is ghostwriting for are mainly the maintainers of the PaX and grsecurity out-of-tree security patchsets. I'll mention in advance that I'm -- mostly -- a big fan of those patchsets and the three people who maintain them. (To my distress, starting Sept. 2015, stable patchsets of grsecurity are available only to paid customers and sponsors: https://grsecurity.net/announce.php ) https://pax.grsecurity.net/ https://en.wikipedia.org/wiki/PaX http://grsecurity.net/ https://en.wikipedia.org/wiki/Grsecurity One cynic's take on this who article might be that it's all about PaX Team / grsecurity people's sudden attempt to monetise their work. Hmmm.... There is a history of Torvalds and other core kernel coders having a difficult relationship with some dedicated security people, including the PaX and grsecurity teams. The latter tend to (IMO, justifiably) inflame this relationship by questioning the kernel's community's handling of security bugs and the accuracy of the kernel's documentation about security problems. Torvalds has often expressed the view that dedicated security people are oddballs, and he doesn't think the same way, or want to. And, seven short paragraphs in, Timberg switches without comment from speaking of Linux as a kernel to Linux as an operating system. Even though he was talking a paragraph before about the problem being 'Linus doesn't take security seriously', now it's: The rift between Torvalds and security experts is a particular source of worry for those who see Linux becoming the dominant operating system at a time when technology is blurring the borders between the online and offline worlds.... Eh? Why are the rift between Torvalds and _certain_ security experts of concern outside the kernel? But I need to ignore Timberg doing this, or I'd be stuck on it for a long time. Suffice it to say, he does this sort of thing throughout. Moving along: Even without a potential nuclear disaster, the stakes are high. Operating system kernels are the most essential code on any computer, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ allowing hardware to work smoothly with multiple pieces of software. Meaningless gibberish. Now, consider this: The Linux kernel runs on the New York Stock Exchange, every Android smartphone and nearly all of the world’s supercomputers. Much of the rapidly expanding universe of connected devices uses Linux, as do many of the world’s biggest companies, including Google, Facebook and Amazon.com. Since the only thing all those uses have in common is specifically the _kernel_ (e.g., Android uses its own libc, and even the kernel is pretty seriously non-standard), the rest of the piece should be about the kernel, right? It's not. Timberg has a long digression where he chides Torvalds's habit of ranting online at any kernel regular whose kernel patch breaks userspace. Timberg's point, the connection to kernel security, was unclear until we reach this bit: The effect of Torvalds's approach to managing the kernel -- defensive, gradualist, sometimes cranky -- chilled debate about the security of Linux even as it became a bigger, richer target for hackers. The result, critics argue, is that while Linux in its early days was widely considered a safer choice than Windows or other commercial operating systems, the edge has dwindled and perhaps disappeared. Excuse me, but Torvalds yelling at his immediate kernel-maintenance lieutenants over patches that break userspace has 'chilled debate about the security of Linux'? Such total bullshit. Someone, e.g., perhaps a PaX team member, has fed Timberg a passive-aggressive line and he fell for it. No, Torvalds yelling at his trusted lieutenants for breaking userspace has _not_ chilled debate about the security of the Linux kernel. E.g., the PaX and grsecurity maintainers cheerfully state their views on the Linux kernel mailing list without reservation, and they don't even get yelled at for doing so. The grsecurity and PaX patchsets have never had a prayer of a chance of being merged into mainline kernels. And why is that? Because they change kernel semantics and break some things. As usual, tightening security has serious costs. Also, the patchsets can be applied cleanly and functionally to only _certain_ kernel releases. This addresses, in part, the enduring rift between the core kernel team (not, as Timberg would suggest, just Torvalds) and dedicated security people: The core kernel team feel that the security people are 'crazy' in the sense of having little appreciation of the many interests that an OS kernel must serve and the style of governance required for a rapidly changing codebase. Torvalds and Co., with total justification, feel that if they ran the kernel the way the security people wished they would, progress would slow to a snail's pace, and a lot of functionality would simply break. You can already have a kernel with painfully careful attention to security. It also has a glacial development process, abysmal scope of supported hardware, and regrettably bad performance. It's called OpenBSD. What Timberg _could_ have reasonably said about 'debate about the security of Linux' is not that Torvalds 'chills' it -- which is utter nonsense -- but rather that it tends to be frustratingly un-fruitful because the core kernel people aren't security professionals and lack that mindset. Hence, the two sides of that discussion have little meeting of the minds, and tend to talk past each other. [Article quotes Matthew Garrett, now principal security engineer for CoreOS, as saying that cutting edge security work hasn't been applied to the mainline kernel, and so isn't as secure as man people would wish it to be, and then:] Versions of Linux have proved vulnerable to serious bugs in recent years. AshleyMadison.com, the Web site that facilitates extramarital affairs and suffered an embarrassing data breach in July, was reportedly running Linux on its servers, as do many companies. Those problems did not involve the kernel itself, but [...] Hey, Mr. Timberg? What did you just do there? The kernel hasn't had as good a security record as it might, says Garrett, and so just look at the compromise of AshleyMadison.com! Except, of course, that (very, very probably) didn't involve the kernel. (To the best of my ability to tell, the compromise vector used for AshleyMadison.com was never disclosed and might not even be known. In my experience of such cases, it's astronomically more likely to be some stupid administrative error, an inside job, or bad userspace code than a kernel security problem.) So, what are you saying, Mr. Timberg? He goes on: [...] but experts say the kernel has become a popular target for hackers building 'botnets,' giant networks of computers that can be organized to initiate cyberattacks. And your point is what, Timberg? By the way, as someone who's done security for a long time, the Linux kernel is, on balance, one of the components I worry _least_ about. And for critical systems, there are hardening kits (including PaX and, until just recently, grsecurity). Kernels are almost never the problem. The problem overwhelmingly is vulnerable, badly designed, and/or ridiculously overfeatured applications. It should also be noted carefully that the hardening strategies typically concentrate _mostly_ (verging on overwhelmingly) on making the Linux kernel better protect vulnerable userspace code from successful attacks from outside -- mitigating application exploits. Almost none of the work is directed at fixing kernel correctness and mitigating kernel exploit modes. Ironically, the only clear example of the latter I can point to came _from a mainline kernel coder_, Andrea Anrcangeli, and is a kernel feature (since 2.6.12, this past March) called 'secure computing mode' or 'seccomp'. It is -- finally -- a totally effective sandboxing security for application code. See: https://en.wikipedia.org/wiki/Seccomp This came from the Torvalds camp. It did _not_ come from the security malcontents who bitched to reporter Timberg. In the former category, protecting vulnerable application code from its own bugs being exploitable, the kernel already does quite a bit, such as ASLR (randomizes the physical and virtual address at which the kernel image is decompressed) and NX (No-eXecute bit marking stretches of memory that shouldn't be executed as not valid to be executed by the CPU). Though neither of these is foolproof. By the way, support for NX is one major advantage that's come painlessly with x86_64, and is yet another reason to lose those ancient IA32 boxen -- though the PaX patchset makes NX work on (some?) IA32 boxes. Kees Cook has been starting to coordinate information about both types of kernel-based protective techniques: http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project And for four years, there has been an active and influential kernel-hardening mailing list: http://www.openwall.com/lists/kernel-hardening/ Timberg stresses that Torvalds doesn't want to merge a number of such out-of-tree security patchsets. OK, and your point, Mr. Timberg? Do you think everyone has to run a mainline kernel for security-sensitive applications? Because we don't. (Users overwhelmingly don't run kernel.org kernels _anyway_. They run vendor kernels, which typically merge some non-mainline security patches but not others.) Timberg's basic song is that kernel security could be better. Well, gosh, welcome to the real world, Mr. Timberg. Security of any codebase could always be better. The question is cost, in time, money, complexity, difficulty of debugging, adverse consequences on other code, and similar things. Security is always an economic calculation. Add hardening, add role-based access controls, reduce risky and unwanted functionality, and you put a much bigger burden on users and administrators to know what they're doing. This is a reason why the patchsets aren't default. This is why even the biggest adopters of SELinux (RHEL, Fedora) apply it only very tentatively ('targeted policy'). Timberg quotss Kees Cook as describing the horrors of what an attacker could do who 'gained control of the Linux kernel itself' without bothering to say that this is like saying 'If I had wings and really low gravity, I could fly.' [Grsecurity's Brad Spengler] soon demonstrated how nearly a dozen known Linux coding bugs could be exploited by malicious hackers to defeat external defenses and take control of the kernel. Yes? Where? I read LWN.net and that I seem to recall this is a serious exaggeration. Let's see, 2010 interview with Spengler: 'The only comments I make are on LWN (like when Ingo was spreading lies about the perf_counter vulnerability) or in exploit headers, because they seem to respond to that (or rather, the commercial influences care about the media publicity generated by such things, which causes them to improve security). It took 8(!) public exploits for null pointer dereference bugs to be fixed as a privilege escalation vector. Granted, after the first public exploit, mmap_min_addr was introduced some months later, but the Linux developers who aren't really security people aren't very good at introducing security features. mmap_min_addr has had at least half a dozen different bypasses since its inception for such a small, simple feature.' https://slo-tech.com/clanki/10001en/ So, misrepresentation by Timberg (probably out of lack of comprehension) of what Spengler showed. Layman's explanation: http://www.zdnet.com/article/linux-exploit-gets-around-security-barrier/ LWN.net coverage: http://lwn.net/Articles/341773/ In short, privilege-escalation. Privilege escalation is a Very Bad Thing, but is not the same as 'coding bugs [that] could be exploited by malicious hackers to defeat external defenses and take control of the kernel'. That is a gross exaggeration. It should also be mentioned that Spengler's beef was primarily with Red Hat's '2.6.18' vendor kernel (which the exploit sliced through without regard to SELinux), _not_ with kernel.org's tree, which had already been patched for 11 days to fix that very problem, when he published his exploit. See: http://lwn.net/Articles/341912/ Torvalds also resisted suggestions that security deserved a special place in the hierarchy of concerns faced by software makers. All flaws, in his view, were equally serious. Bullshit. This is not his view. This attitude was enshrined in a public posting in July 2008 that said: "I personally consider security bugs to be just ‘normal bugs.’ I don't cover them up, but I also don’t have any reason what-so-ever to think it's a good idea to track them and announce them as something special." This is simply not the same as claiming that all flaws are equally serious -- and Timberg either knew this when he made the claim or should have. But in his recent interview with The Washington Post, Torvalds rejected the notion that bugs could be usefully sorted into categories. "I refuse to waste a second of my life -- or any other developer's life -- trying to classify something that can’t be classified," he said. Torvalds has some significant justification for his view, as Timberg would know if he either studied security or consulted more people about the story than just a couple of security folk with grudges. I'm guessing Torvalds's view is that attempting to highlight a specific class of 'security' bugs would be futile because it's often very non-obvious at the time of discovery what bugs will turn out to have security implications, and the time required to make that determination would be better spent just fixing the bugs and moving on. And there are decades of history that tend (for the most part) to support Torvalds in this view. Despite providing a steady supply of defensive innovations, Spengler did not become a popular figure within the upper reaches of the Linux community, where he was seen as extreme in his views and sometimes brittle in his manner. Well, he is. His comments pretty much everywhere come across as sarcastic and bitter. There is no systemic mechanism for identifying and remedying problems [in the Linux kernel] before hackers discover them, or for incorporating the latest advances in defensive technologies. And there is no chief security officer for the Linux kernel. Nor is there a Santa Claus.[1] Chief security officers, where they exist, tend to be preplanned scapegoats for whenever the next security catastrophe occurs. Because, honestly, what organisation is make the guy actually the project czar? That just doesn't happen, so inevitably it's an advisory position without significant decision authority -- and a scapegoat. In the years since Spengler and others began warning about the security of Linux, it has triumphed in the marketplace. Google released its first version of the Android mobile operating system, which is based on Linux, in 2007, allowing Torvalds's work to reach hundreds of millions of smartphones each year. Google also made the kernel the basis of Chrome OS, which is used in an increasingly popular category of cloud-based computers called Chromebooks. Of course, these are significantly modified _forks_ of Torvalds's work. Now, watch for the hat-trick where Torvalds & Co. get slagged for not only the forked Google kernels but also for Google's notoriously lax userspace third-party ecosystem. Cue it in one... two... ...Three! Hackers are more likely to prey upon Oracle's Java and Adobe's Flash and Acrobat. All of which are extremely deprecated in standard Linux -- because they are security basket cases, and not safe to expose to arbitrary files on the Internet. (I don't know about Acrocrud on Android and ChromeOS, but I doubt it.) More recently, in 2014, Linux devotees were unhappy to discover that an Italian surveillance company called Hacking Team had swiftly turned a Linux exploit known as "towelroot" into a skeleton key capable of gaining access to hundreds of millions of Android phones. Which involved Android's failure to patch a June 2014 Linux kernel bug (CVE-2014-3153) in the futex subsystem (fast userspace mutex locking) that could be exploited by a local process to escalate to root privilege. All distros already had fixed kernels out by the time CVE-2014-3153 was published on June 5, 2014. It was a ghastly coding error, and a serious failure -- but the point is that standard Linux fixed it promptly. Why didn't Android? The answer to that is easy and has everything to do with the Google code ecosystem and nothing to do with Linux: It happened because the Android ecosystem has a horribly broken approach to code maintenance -- unlike standard Linux. This is less Google's fault than it is the institutional laxity built into Google's basic agreement with the Open Hardware Alliance OEMs, in which the OEMs are in the driver's seat and not Google. A hardened variant of CyanogenMod (which itself is a totally open source variant form of Android) now exists, called CopperheadOS: https://copperhead.co/android/ I don't know whether their hardened kernel would have evaded the rather ghastly CVE-2014-3153 bug, even though the project boasts 'a PaX kernel, OpenBSD's hardened allocator and compiler hardening features'. But for damned sure, the project's far more likely to actively respond to serious problems than regular Android in the field is, since the latter's functionally little different from 'Use what got preloaded until the device dies.' It should be mentioned in passing that kernel problems in Android don't even rate: The real problem in Android is the ubiquitous attitude of it being OK to run any old code, proprietary or not, out of anywhere. This guarantees security problems that dwarf anything involving the kernel. [skipping discussion of a August 2015 Linux Security Summit keynote address about lurking security problems by Linux Foundation sysadmin Konstantin Ryabitsev[0], and some reactions to that keynote] "We have some measures in place, although we are really not doing everything we can," wrote James Morris, maintainer of Linux's exterior defenses against attackers. That is _not_ James Morris's remit, by the way. Timberg once again did not bother to do basic fact-checking. Morris maintains the LSM (Linux Security Modules) subsystem, the kernel's interface for access control software such as SELinux.[1] LSM is sometimes inaccurately described as 'Linux's security subsystem' -- as if security can be accomplished by containing it within a subsystem -- so Timberg probably picked up the grossly inaccurate description from one of those. But it's yet another thing he flubbed by not doing fact-checking. Good article by Morris, putting LSM in context: https://www.linux.com/learn/docs/727873-overview-of-linux-kernel-security-fe... Timberg cites an encounter between Kees Cook and Torvalds at the 2015 Linux Summit, where Cook promoted some ideas from Morris's Linux Security Summit keynote, including some specific items from PaX / grsecurity, and: The ability to make the kernel execute code in user-space memory is exploitable. The best solution here can be hardware segmentation; Intel's "supervisor-mode execution prevention" and ARM's "privileged execute never" can both block execution from user-space memory. Instrumenting the compiler to set the high address bit on all kernel function calls can block calls into user-space memory (since the kernel's address space is at the upper end of the virtual address range, while user space is at the bottom). Kees also suggested emulating segmentation by using separate page tables for user mode and kernel mode; Linus jumped in at this point to say that this is the kind of idea that makes security people look crazy; such an approach would never perform well. He suggested avoiding talking about ideas that will clearly never make it into the mainline. http://lwn.net/Articles/662219/ It's speculative _how_ big a performance hit this radical idea would exact, but big, anyway. And Torvalds has a point: huge hits to performance just so the kernel can compensate for egregious coding errors in some applications would be wildly unpopular in _general-usage_ kernels. Timberg portrays this as if it were a questionable reaction: There was a revealing moment, however, when Cook raised the possibility of adding an especially intrusive feature long offered by Grsecurity. Torvalds immediately spoke up, saying this was "the kind of idea that makes security people look crazy," according to LWN.net, a site that follows Linux issues. Some 'security' patches don't have big performance hits or have serious functionality impact. To my knowledge, they get mainlined just as often as any other patches -- but part of the point of Torvalds's 'a bug is a bug' (and therefore a bug labelled 'security' is per-se just a bug) attitude that the security gang dislike is that just about _any_ bug might turn out to have security implications, so why privilege some just because of whom they arrive from, or what tag someone attaches, without other reasons? 'Security' patches certainly do get mainlined. They have an easier time doing so if credibly introduced on LKML, and easier if they are modest in scope rather than a huge stupendous change all at once, and easier if they don't break userspace. If those conditions aren't met and the security practitioner in question gets impatient, maintaining a patchset out-of-tree still works. Just ask the PaX / grsecurity people. Who, by the way, aren't even proposing their patches on LKML because they want to get paid mucho dinero for doing so (see: https://lwn.net/Articles/538600/), so it's not surprising they don't get mainlined. So, what's the complaint, again? Timberg closes with a comparison of the Linux ecosystem to the city of Troy, and rhetorically asks who's protecting the Trojans? Well, Mr. Timberg, those who want the occasional serious inconveniences and reduced performance of including the more-far-reaching security patchsets are doing so, on their security-sensitive systems. Those who care less about hardening, which is _mostly_ protecting badly written userspace applications from the consequences of those bugs, aren't. It's called choice and diversity. Some people aren't used to it. It's nowhere near perfect, and there are bugs in all code, and death and taxes also exist. And no surviving citizens of Troy, either. I'll let Spender have almost the last word, because even though he's a cranky-pants gadfly with a questionable sense of perspective, I like him anyway. Slides: https://grsecurity.net/spender_summit.pdf And I'm going to be curious what security-sensitive people do to compensate for the sudden restricted availability of grsecurity. But in conclusion: Sure, security in the Linux kernel is a huge, fat mess, there are problems that persist for rather too long, and there have been far too few attempts at _systemic_ improvement as opposed to the patch-and-pray treadmill. Same old. Timberg seems to _want_ to imagine a magic world where everyone can be made simultaneously happy with a single reformed/refactored kernel source tree arrived at without major delays and expense. Worse, he blames a bunch of things on Torvalds & Co. that are not within their remit at all. Worst of all, Timberg served mostly as a stalking horse for a little gang of security people with grievances but no real clue how to run a kernel project and why. These are _my_ kind of malcontents, but I'm aware that they're out of their depth when they suggest Torvalds & Co. are running the project wrong. Timberg isn't, and IMO got taken for a ride. We needed a good article about the perennial standoff between the core kernel people and security specialists. This was about 1/3 of one. There are real concerns. This article at least puts them on the table, though it does a poor job of discussing them. [0] See also http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf Highly recommended, and extremely funny & wise stuff. I have lived this. [1] It would be an excellent if antiquated gag to rename a village within the Commonwealth of Virginia to be called 'Santa Claus, Virginia'. Except, you'd never be able to find it with a search engine. [2] Morris is also maintainer of sVirt for virtualisation software and of the kernel crytographic API, has done work on SELinux, and does other security work in the kernel. I don't want to denigrate his work, which is important. He's a Red Hat employee living in Sydney. _______________________________________________ conspire mailing list conspire@linuxmafia.com http://linuxmafia.com/mailman/listinfo/conspire ----- End forwarded message -----

Hi all,
Add hardening, add role-based access controls, reduce risky and unwanted functionality, and you put a much bigger burden on users and administrators to know what they're doing. This is a reason why the patchsets aren't default. This is why even the biggest adopters of SELinux (RHEL, Fedora) apply it only very tentatively ('targeted policy').
In reality, I have seen a lot of servers which disable the enforced policy. It is a good reason why Theo de Raadt dismissed it recently in a slide show (sorry, cannot find it at the moment.) It s tricky if you do things differently as intended by the writer of the policies. You practically have three choices: 1. Just leave things as they are, don't touch anything. Do careful manual configuration 2. Hopefully someone has written some kind of tool to take care of it and applies it as part of your configuration manegement 3. Read the policy writer's mind and figure out what you can do, and spend significant time to make your changes work with SELinux. 4. Just give up. "My boss is in a hurry so I turn it off." The problem becomes worth if you deal with proprietary software. I just had a webhosting software which is starting perl processes, MySQL and apaches with configuration files and binaries all over the place. Good luck to make it work.. Compare this with jails: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html (and follow the advice at the bottom!) If you are prepared you can spin up a jail in a few seconds, start your process and know that it can only mess around with a restricted environment unique to this process/package/app. Unfortunately, the equivalent is not that secure in the Linux environment. https://www.linux.com/learn/docs/727873-overview-of-linux-kernel-security-fe... Namespaces <http://lwn.net/Articles/531114/> in Linux derive from the Plan 9 operating system (the successor research project to Unix). It's a lightweight form of partitioning resources as seen by processes, so that they may, for example, have their own view of filesystem mounts or even the process table. This is not primarily a security feature, but is useful for implementing security. One example is where each process can be launched with its own, private /tmp directory, invisible to other processes, and which works seamlessly with existing application code, to eliminate an entire class of security threats. The potential security applications are diverse. Linux Namespaces have been used to help implement multi-level security, where files are labeled with security classifications, and potentially entirely hidden from users without an appropriate security clearance. On many systems, namespaces are configured via Pluggable Authentication Modules (PAM)--see the pam_namespace(8) man page. --- When you use FreeBSD, you will find that you do not have /proc, and you do not have /sys . You only have /dev populated by devd and that's it. And if you have a jail and use the default dev.rules, you may find only pseudo devices as /dev/zero and /dev/null, that's it. You may have, furthermore, securelevel - see security(7): http://www.freebsd.org/cgi/man.cgi?query=security&sektion=7&apropos=0&manpat... It is easy to use chflags(1) to harden a system so the /bin, /usr etc. directories (and files) are immutable. (BTW: You can get around the patching issue inside jails with templates spinning up new jails when needed, if you configure them to replace the running instance). These methods seem to me much simpler then the SELinux and all the systemd, udev, /proc, /sys, SELinux, dbus/polkit/hald.. "magic". These much more complex approaches all scream "Just trust me, I have 2500 rules and they are all written well", and they are, in real life, commonly ignored by administrators as well as providers of proprietary software. Yes, security feels a lot like an afterthought of the "Linux environment". Note, the tools above are there for many years, while the container security(e.g.) is still a lingering issue under Linux. BTW: I am aware that I am not restricting myself to the Linux kernel only. Also: FreeBSD is not the only *BSD environment, there is NetBSD, OpenBSD, DrangonFlyBSD, NextBSD - I mention FreeBSD because I chose it for a number of reasons a while ago and now best. But it does not ay, it is the only "cool BSD". Others are definitly worth checking out:-) Russell asked me a while ago about a BSD talk. Apologies, life and work were in the way in many ways and my progress is "at glacial speed as OpenBSD" as the saying goes but I have a new toy (a dedicated server), am about polishing my older scripts to speed up deployments, and happy to talk about it (and others) in the not to distant future. I am accompany my activities with notes at the moment. Regards Peter

Quoting Peter Ross (petrosssit@gmail.com): [SELinux 'targeted' policy:]
In reality, I have seen a lot of servers which disable the enforced policy.
I worked at a very large EDA-industry company in the 2000s that, per corporate mandate, disabled SELinux on _all_ of its RHEL deployments. As a member of the Linux Management department, this pretty much made me dispair of the firm surviving, let alone developing clue.
It is a good reason why Theo de Raadt dismissed it recently in a slide show (sorry, cannot find it at the moment.)
Can't find that either, but he had a recent (June) post to his 'tech' mailing list talking about the complexity introduced by programs written in the Berkeley packet filter (BPF) language being 'insane', those being dictated by SELinux's invocation of the seccomp() syscall to do all but the simplest sandboxing. Reference here: https://lwn.net/Articles/651700/
BTW: I am aware that I am not restricting myself to the Linux kernel only.
As is appropriate! BTW, I assume many have read the news about grsecurity going restricted for somewhat understandable reasons. https://grsecurity.net/ Important Notice Regarding Public Availability of Stable Patches Due to continued violations by several companies in the embedded industry of grsecurity's trademark and registered copyrights, effective September 9th 2015 stable patches of grsecurity are being made available to sponsors and commercial support customers only. For more information, read the full announcement. [link] Dismaying. I am curious what the commentariat considers best practices hardening for Linux kernel + userspace in the wake of this announcement. PaX, AppArmor...? -- Cheers, (morganj): 0 is false and 1 is true, correct? Rick Moen (alec_eso): 1, morganj rick@linuxmafia.com (morganj): bastard. McQ! (4x80) -- seen on IRC

Noted in recent list traffic: From: Rick Moen via luv-main <luv-main@luv.asn.au> ^^^^^^^^^^^^^^^^^^^ ...replacing my actual From: Rick Moen <rick@linuxmafia.com> I respect the reasons Russell has introduced this munging, but it's regrettable in its main effects. FYI, for anyone needing to contact me offlist: Almost all of my .signature blocks furnish my e-mail address. Said footer address should thus be consulted, given that LUV's mailing lists have now been configured to discard & replace posters' 'From: ' headers with ones of Mailman's own devising. -- Cheers, (morganj): 0 is false and 1 is true, correct? Rick Moen (alec_eso): 1, morganj rick@linuxmafia.com (morganj): bastard. McQ! (4x80) -- seen on IRC

Rick Moen via luv-main <luv-main@luv.asn.au> writes:
FYI, for anyone needing to contact me offlist: Almost all of my .signature blocks furnish my e-mail address. Said footer address should thus be consulted, given that LUV's mailing lists have now been configured to discard & replace posters' 'From: ' headers with ones of Mailman's own devising.
Note that the Reply-To header is also set: Reply-To: Rick Moen <rick@linuxmafia.com> So if your mail client is behaving, private replies should get to you as private replies. (Yes, I know, replacing the Reply-To is also controversial) -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

Quoting Brian May via luv-main (luv-main@luv.asn.au):
Note that the Reply-To header is also set: Reply-To: Rick Moen <rick@linuxmafia.com>
Yes, good point. Thank you.
So if your mail client is behaving, private replies should get to you as private replies.
(Yes, I know, replacing the Reply-To is also controversial)
The reason it's not only controversial but (since 2001) definitively a breaking of standards-compliant behaviour is that it overrides, discards, and replaces the sender's own legitimate user of that SMTP feature, as IETF reconfirmed in 2001 via RFC 2822: It is an optional SMTP feature in which the sender may indicate a desired reply-sender return address. RFC 2822 section 3.6.2 said about 'Originator fields': When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. Mailing list software is not "the author of the message", so it should not set or alter the Reply-To header field. Said field is for the author's use. For example: If transitioning from 'rick@linuxmafia.com' to 'rick@unixmercenary.net', I might set 'Reply-To: Rick Moen <rick@unixmercenary.net>' in mail headers, signaling that any reply-sender responses should go to the latter. That is the intended and legitimate use of the header, other views prior to IETF settling the issue in 2001 notwithstanding. Any mailing list that discards & replaces the user's use of this optional header is interfering with user intentions and deliberately breaking Internet standards. The related question of 'How, then, should the desired reply-list address be signaled?' was answered in IETF's other 2001 statement on the issue, RFC 2369: The method of posting to the list can be stated in a List-Post header. Please see section 3.4 of that standards document for details if interested. With those two IETF standards documents, all legitimate controversy over Reply-To ended. Munging is not a legitimate use. -- Cheers, In time of crisis, people do not rise to the occasion; Rick Moen they default to the level of their training. rick@linuxmafia.com McQ! (4x80)

Rick Moen via luv-main <luv-main@luv.asn.au> writes:
The reason it's not only controversial but (since 2001) definitively a breaking of standards-compliant behaviour is that it overrides, discards, and replaces the sender's own legitimate user of that SMTP feature, as IETF reconfirmed in 2001 via RFC 2822: It is an optional SMTP feature in which the sender may indicate a desired reply-sender return address.
I also find it confusing in that some mailing lists set Reply-To: to the mailing list, and others such as LUV set it to the sender. Some mailing lists I have to "reply-to-sender" to reply to the list, others I have to use "group-reply", yet others I have to use "group-reply" and then manually alter the To: and Cc: headers to ensure I don't get flamed for CCing people who don't want to get CCed. Yes, sure there are lots of debates and dicussions about which one is "right" or "wrong", however it is a shame that there isn't a single standard that everyone adheres to for how to process the headers for mailing lists. Will stop there, before I start complaining about the lack of flying pigs in my area. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

Quoting Brian May via luv-main (luv-main@luv.asn.au):
I also find it confusing in that some mailing lists set Reply-To: to the mailing list, and others such as LUV set it to the sender.
Yes. Neither should occur. It's not the mailing list's header to set, but rather the user if he/she has a use-case where it is useful.
Some mailing lists I have to "reply-to-sender" to reply to the list, others I have to use "group-reply", yet others I have to use "group-reply" and then manually alter the To: and Cc: headers to ensure I don't get flamed for CCing people who don't want to get CCed.
Reply-all MUA semantics is the normal and intended, standards-compliant way to respond to groups (including to mailing lists). This works even on mailing lists whose administrators meddle with Reply-To:. If your MUA doesn't do that, file a bug. Reply-sender MUA semantics is the normal and intended, standards-compliant way to respond to sender only. This works except where a mailing list adminstrator has made standards-infringing use of Reply-To:, in which case the user must act to manually overcome that obstacle. Absent that artificial obstacle, if your MUA's reply-sender functionality doesn't work, file a bug. This is why MUAs have two 'reply' modes. (Back in the early 1990s, a few MUAs existed that (allegedly) couldn't yet do reply-all. They're no longer around.)
Yes, sure there are lots of debates and dicussions about which one is "right" or "wrong"....
IETF settled the alleged debate in 2001 via RFCs 2822 and 2369. http://linuxmafia.com/~rick/faq/netiquette.html#replyto People still arguing either haven't gotten the message over the last 14 years, or refuse to heed it.
...however it is a shame that there isn't a single standard that everyone adheres to for how to process the headers for mailing lists.
There _is_ a single standard. Some people choose to violate it.

On 25/11/2015 11:19 AM, Rick Moen via luv-main wrote:
Reply-all MUA semantics is the normal and intended, standards-compliant way to respond to groups (including to mailing lists). This works even on mailing lists whose administrators meddle with Reply-To:. If your MUA doesn't do that, file a bug.
Reply-All is a pain on a mailing list, because of the extra To: and Cc: addresses that are sent to by default (unless manually removed), but some MUAs have a "Reply List" feature, which has the desired effect of generating a single reply to the list. Works really well on lists like this one (i.e. without Reply-To: munging), I can have all 3 options: Reply - replies to the sender Reply List - replies to mailing list only Reply All - replies to the list and sender(s) FWIW, I use Thunderbird. And yes, Reply-To: munging breaks this badly.
Reply-sender MUA semantics is the normal and intended, standards-compliant way to respond to sender only. This works except where a mailing list adminstrator has made standards-infringing use of Reply-To:, in which case the user must act to manually overcome that obstacle. Absent that artificial obstacle, if your MUA's reply-sender functionality doesn't work, file a bug.
This is why MUAs have two 'reply' modes.
3 modes is better - sender, list and all. I use the "List" option a lot, dramatically reduces clutter, especially in long threads.
(Back in the early 1990s, a few MUAs existed that (allegedly) couldn't yet do reply-all. They're no longer around.)
Yes, sure there are lots of debates and dicussions about which one is "right" or "wrong"....
IETF settled the alleged debate in 2001 via RFCs 2822 and 2369. http://linuxmafia.com/~rick/faq/netiquette.html#replyto
People still arguing either haven't gotten the message over the last 14 years, or refuse to heed it.
History and an ever present stream of noobs mean Reply-To: munging will linger for a long time, even though we have both the mailing list and MUA software to properly handle all replies without having to munge anything. :( -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On Wed, Nov 25, 2015 at 04:55:24PM +1100, Tony Langdon via luv-main wrote:
[...] Works really well on lists like this one (i.e. without Reply-To: munging), I can have all 3 options:
this list now does Reply-To: munging as well as From: munging.
Reply - replies to the sender Reply List - replies to mailing list only Reply All - replies to the list and sender(s)
mutt does all three. i almost always choose Reply All (or 'g' for group reply in mutt) so I can edit the To: and CC: headers in vi, and can delay choosing whether the reply is going to be private or to the list until after I've written it. but not on this list any more. The From: and Reply-To: headers are both messed up.
And yes, Reply-To: munging breaks this badly.
yes
History and an ever present stream of noobs mean Reply-To: munging will linger for a long time, even though we have both the mailing list and MUA software to properly handle all replies without having to munge anything. :(
worse, this DKIM nonsense is bringing it back, and munging the From: header as well as the Reply-To: header. craig -- craig sanders <cas@taz.net.au>

On Wed, Nov 25, 2015 at 07:45:33PM +1100, Craig Sanders via luv-main wrote:
but not on this list any more. The From: and Reply-To: headers are both messed up.
All three reply styles - 'r', 'g', and 'L' - reply to the list and zero other addresses. The 'r' private reply would probably work if i didn't have long-standing procmail rules to partially work around the damage of Reply-To munging. craig -- craig sanders <cas@taz.net.au>

On 25/11/2015 7:48 PM, Craig Sanders via luv-main wrote:
On Wed, Nov 25, 2015 at 07:45:33PM +1100, Craig Sanders via luv-main wrote:
but not on this list any more. The From: and Reply-To: headers are both messed up.
All three reply styles - 'r', 'g', and 'L' - reply to the list and zero other addresses.
OK, further testing reveals that Reply and Reply List work properly in Thunderbird, but Reply All doesn't, it only includes the list address (not the sender). So you are correct, it is technically broken. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 25.11.15 19:48, Craig Sanders via luv-main wrote:
On Wed, Nov 25, 2015 at 07:45:33PM +1100, Craig Sanders via luv-main wrote:
but not on this list any more. The From: and Reply-To: headers are both messed up.
All three reply styles - 'r', 'g', and 'L' - reply to the list and zero other addresses.
The 'r' private reply would probably work if i didn't have long-standing procmail rules to partially work around the damage of Reply-To munging.
Sounds likely. Here, only 'g' fails as you describe, when replying to your posts. Interestingly, 'r', 'g', and 'L' all work correctly on Tony's posts, & Rick's, and Brian's. (And yet, Reply-To: is similar in all. Tried it 5 times, and can't for the life of me see why yours behave differently.) Erik

On 25/11/2015 9:13 PM, Erik Christiansen via luv-main wrote:
Interestingly, 'r', 'g', and 'L' all work correctly on Tony's posts, & Rick's, and Brian's. (And yet, Reply-To: is similar in all. Tried it 5 times, and can't for the life of me see why yours behave differently.)
Same result here. Only Craig's posts don't allow me to reply to all. This function worked properly with your post just now, Erik. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On Thu, Nov 26, 2015 at 09:08:50AM +1100, Tony Langdon via luv-main wrote:
On 25/11/2015 9:13 PM, Erik Christiansen via luv-main wrote:
Interestingly, 'r', 'g', and 'L' all work correctly on Tony's posts, & Rick's, and Brian's. (And yet, Reply-To: is similar in all. Tried it 5 times, and can't for the life of me see why yours behave differently.)
Same result here. Only Craig's posts don't allow me to reply to all. This function worked properly with your post just now, Erik.
now that's really bizarre. I can understand why my MUA (mutt) has difficulty with Reply-To (because I have a procmail rule to rename that header to X-Old-Reply-To to defeat the Reply-To munging of some lists, so there is no Reply-To header for mutt to use). But there's no reason why a message I send to this list should be any different to a message sent by someone else. I do make a habit of trimming the CC: header unless I really want to send a CC to someone, which doesn't happen often - I usually want to send either a list reply or a private reply, almost never both. craig -- craig sanders <cas@taz.net.au>

On Thu, 26 Nov 2015 09:08:50 AM Tony Langdon via luv-main wrote:
Same result here. Only Craig's posts don't allow me to reply to all. This function worked properly with your post just now, Erik.
That seems to be a Thunderbird bug, it works fine for both Craig and Eriks emails when I reply-all in Kmail. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

On 26.11.15 21:30, Chris Samuel via luv-main wrote:
On Thu, 26 Nov 2015 09:08:50 AM Tony Langdon via luv-main wrote:
Same result here. Only Craig's posts don't allow me to reply to all. This function worked properly with your post just now, Erik.
That seems to be a Thunderbird bug, it works fine for both Craig and Eriks emails when I reply-all in Kmail.
Weirder and weirder. I'm using: User-Agent: Mutt/1.5.21 (2010-09-15) which shows the "Thunderbird" response to Craig's posts. Now if we only knew what Kmail is handling, that other MUAs don't. Erik

Peter,
Compare this with jails: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
How do BSD jails address letting two services talk to one another, in a limited way? For example, postfix wants to talk to dovecot's SASL implementation over a unix socket. The way this works for me at the moment (on Linux) is that one opens a socket in the other's chroot area, before chrooting into its own area. Because it was already open before chroot(2), it can continue using it.

Hi Trent,
How do BSD jails address letting two services talk to one another, in a limited way?
For example, postfix wants to talk to dovecot's SASL implementation over a unix socket.
The way this works for me at the moment (on Linux) is that one opens a socket in the other's chroot area, before chrooting into its own area. Because it was already open before chroot(2), it can continue using it.
I do not think you can do it this way (Well, if you would reprogram and use jail(2) or jail_attach(2) in the code instead of chroot(2)?.. besides, it would be one way of writing code for BSD only, a bit of a revenge for the Linuxisms find elsewhere;-) Of course you can run both in the same jail and do the "usual" chroot. Or you have them in separate jails and use TCP/IP. Regards Peter On Fri, Nov 27, 2015 at 11:07 AM, Trent W. Buck via luv-main < luv-main@luv.asn.au> wrote:
Peter,
Compare this with jails: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
How do BSD jails address letting two services talk to one another, in a limited way?
For example, postfix wants to talk to dovecot's SASL implementation over a unix socket.
The way this works for me at the moment (on Linux) is that one opens a socket in the other's chroot area, before chrooting into its own area. Because it was already open before chroot(2), it can continue using it.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
participants (8)
-
Brian May
-
Chris Samuel
-
Craig Sanders
-
Erik Christiansen
-
Peter Ross
-
Rick Moen
-
Tony Langdon
-
trentbuck@gmail.com