May/June 2021 SECURITY Seven Ways to Increase Security in a New FreeBSD Installation The copyinout Framework Using TLS to Improve NFS Security Plus: Capsicum Case Study: Got Practical Ports ® J O U R N A L LETTER E d i t o r i a l B o a r d from the Foundation John Baldwin FreeBSD Developer and Chair of • FreeBSD Journal Editorial Board. Justin Gibbs Founder of the FreeBSD Foundation, • President of the FreeBSD Foundation, and a Software Engineer at Facebook. Security Daichi Goto Director at BSD Consulting Inc. • (Tokyo). Information Security has a concept of “Defence in Depth,” a strategy of applying multiple layers of Tom Jones FreeBSD Developer, Internet Engineer • and Researcher at the University of security measures which work in concert to limit the Aberdeen. impact of an attacker gaining unauthorized access to Dru Lavigne Author of BSD Hacks and a system, for example, by exploiting a vulnerability. • The Best of FreeBSD Basics. These layers include techniques applied to the Michael W Lucas Author of more than 40 books including • Absolute FreeBSD, the FreeBSD design of a system or program, those applied during Mastery series, and git commit murder. development, mitigations applied at run-time, and Ed Maste Senior Director of Technology, operational procedures and techniques. • FreeBSD Foundation and Member of the FreeBSD Core Team. The “Principle of Least Privilege” is a technique Kirk McKusick Treasurer of the FreeBSD Foundation that can apply during design and operation. The • Board, and lead author of The Design principle states that a process should operate with and Implementation book series. only those privileges that are required. Tools like static Hiroki Sato Director of the FreeBSD • Foundation Board, Chair of Asia analysis (automated source code analysis) are applied BSDCon, Member of the FreeBSD Core Team, and Assistant during development. Some tools operate on running Professor at Tokyo Institute of software as part of the development process, such as Technology. code-coverage-guided automated fuzzing. American Benedict Reuschling Vice President of the FreeBSD Foundation • Board and a FreeBSD Documentation Fuzzy Lop (AFL) and Syzkaller are two such examples Committer. which have been used to good effect in FreeBSD. Robert N. M. Watson Director of the FreeBSD Foundation Runtime mitigations apply when software is used in • Board, Founder of the TrustedBSD Project, and University Senior Lecturer production. Examples include address randomization at the University of Cambridge. and limitations on memory protection. Finally, Mariusz Zaborski FreeBSD Developer, Manager at operational procedures and techniques include those • Fudo Security. employed by the software author or provider, such as the FreeBSD security team’s process for issuing security advisories, and by the user or sysadmin, such as setting and documenting configuration options. SP O& BWO X 4 0P8 ,U BBE LLF AISTH, MINA I GN E L0 4L9 1C5 Welcome to this security-focused FreeBSD Journal Publisher Walter Andrzejewski issue. We’ll touch on a few different areas related to • [email protected] security, including ports, base system userland and Editor-at-Large James Maurer • [email protected] kernel topics, and system configuration. Design & Production • Reuter & Associates Advertising Sales Walter Andrzejewski • [email protected] Call 888/290-9469 On behalf of the FreeBSD Foundation, Ed Maste Senior Director of Technology FreeBSD Journal (ISBN: 978-0-615-88479-0) is published 6 times a year (January/February, March/April, May/June, July/August, September/October, November/December). Published by the FreeBSD Foundation, 3980 Broadway St. STE #103-107, Boulder, CO 80304 ph: 720/207-5142 • fax: 720/222-2350 email: [email protected] Copyright © 2021 by FreeBSD Foundation. All rights reserved. This magazine may not be reproduced in whole or in part without written permission from the publisher. FreeBSD Journal • May/June 2021 3 May/June 2021 8 Seven Ways to Increase Security in a New FreeBSD Installation By Mariusz Zaborski 14 The copyinout Framework By Konrad Witaszczyk 25 Using TLS to Improve NFS Security By Rick Macklem 33 Capsicum Case Study: Got By Yang Zhong 3 Foundation Letter By Ed Maste 5 We Get Letters Dear They’ll Blame Me for Ransomware by Michael W Lucas 39 Practical Ports Security Scanning a Jail By Benedict Reuschling 43 Events Calendar By Anne Dickison FreeBSD Journal • May/June 2021 4 1 of 3 by Michael W Lucas freebsdjournal.org Dear Letters Columnist, The boss says “everything must be secure.” I started making a list of things to check for security, and there’s no way I can do all this. What do I do? Thank you, — They’ll Blame Me for Ransomware Oh, TBMfR, my sweet summer child. You hit the “rant” button. Buckle in. I’ve previously written in this very column about how the word “firewall” means nothing. The term is void, without clarity or purpose. The F-word should be removed from your vocabulary immediately, by armed force if necessary, and replaced by a more specific term that means… something. Anything. “Security?” It’s like that, but even more appalling. I will readily concede that out in meatspace, these eight distasteful letters have a role. How would you know which people to avoid without the phrase security guard? Yes, yes, authori- tarian goon could serve in its place, but it doesn’t precisely roll off the tongue. Social Security? That’s a thing. But how do these relate to computing? As always in these cases, I reach for the Single Source of Linguistic Truth: my Oxford English Dictionary, from that delightful Edwardian era best known as World War Intermission. Comput- ers were people then and understood instructions like “lock up the cipher’s secret keys at the end of your shift.” We didn’t have to define locks, or secrets, or ciphers in sufficient detail that a machine designed to the highest standards of malicious obedience couldn’t misunderstand them. Security meant “do it right or the authoritarian goons will smack you until you do.” So, let’s go to the official definition of this word. Wait. The official definition fills most of page 370 and spills over onto 371. There’s no way I’ll quote all that. I’ll skim and cherry-pick some definitions that conveniently support my argument. 1. “The condition of being secure.” Defining a word with its own root? That’s nearly as helpful as the documentation helpdesk staff give users. Moving on. 2. “The condition of being protected from or not exposed to danger; safety.” Here’s my question: does the boss want the staff computers protected from danger, or the staff protected from the dangers of computers? Don’t you dare try to tell me that computers don’t threaten people; I’ve seen YouTube, and don’t get me started on Myspace or Facestagram or whatever they call it these days. FreeBSD Journal • May/June 2021 5 2 of 3 3. “Freedom from doubt; confidence, assurance. Now chiefly, well-founded confi- dence, certainty.” Computers are not only doubt incarnate, they are unapologetic doubt factories, spewing dig- ital uncertainty every millisecond they’re running. We call ourselves engineers, but civil engineers get really upset when a suspension bridge unexpectedly dumps core. It’s the sort of thing that makes the news and gets unpopular employees exiled to Farawayistan to maintain that oh-so- vital sham of accountability. In computing, when a server crashes, we check the logs and see there’s nothing, so we wait to see if it happens again, all the while desperately hoping it doesn’t. Maybe we turn on extra monitoring if we have it. This isn’t a matter of laziness. The tools to identify many problems do not exist, and the ones that do exist are beyond the comprehension of the average sysadmin. You can learn the tools, yes, but when you master them, you have to figure out how to fix them and then it’s too late, you’ve become a developer and your life is essentially concluded. Civil engineers at least have the benefit of being able to go look at their bridges and say helpful things like “This critical bolt is starting to bend, maybe we should stop sending trains full of lead across it while I check it out.” They’ll be told no, of course, but the en- gineers know to save the memos so that when the bridge dumps core the blame flows uphill. If you don’t want doubt, get a different job. Try something with feral hamsters. They’re more rational than computers. 4. “Freedom from care, anxiety, or apprehension; a feeling of safety or freedom from or absence of danger.” Oh heck, I know—I KNOW—that you did not just try to apply “freedom from care” to any- thing in systems administration. Anxiety and apprehension are the soul of technology manage- ment. Confidence is for the organization’s Chief Scapegoat Officer, someone so far removed from the day-to-day operation that they have no idea what’s really going on down in the cubi- cle sewer. People who do the real work understand that computers are untrustworthy. Your test environment is exactly like your production environment, except that the database server has a slightly older CPU lacking two instructions present in production? Guess what’s going to bite you? Hint: it’s not that. You know about that. Rule 44 of systems administration clearly declares that “a perfect deployment means only that you haven’t yet noticed the catastrophe.” If you think this rule isn’t true, you haven’t been paying attention. Your job description should read “go surfing in a blender.” And that’s the real problem.