DOCSLIB.ORG

Opensuse Leap 42.1 Security Guide Opensuse Leap 42.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Opensuse Leap 42.1 Security Guide Opensuse Leap 42.1 Security Guide openSUSE Leap 42.1 Security Guide openSUSE Leap 42.1 Introduces basic concepts of system security, covering both local and network secu- rity aspects. Shows how to use the product inherent security software like AppAr- mor or the auditing system that reliably collects information about any security-rel- evant events. Publication Date: November 05, 2018 SUSE LLC 10 Canal Park Drive Suite 200 Cambridge MA 02141 USA https://www.suse.com/documentation Copyright © 2006–2018 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu- mentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third party trademarks are the prop- erty of their respective owners. A trademark symbol (®, ™ etc.) denotes a SUSE or Novell trademark; an asterisk (*) denotes a third party trademark. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xv 1 Security and Confidentiality 1 1.1 Local Security and Network Security 1 Local Security 3 • Network Security 6 1.2 Some General Security Tips and Tricks 10 1.3 Using the Central Security Reporting Address 12 I AUTHENTICATION 13 2 Authentication with PAM 14 2.1 What is PAM? 14 2.2 Structure of a PAM Configuration File 15 2.3 The PAM Configuration of sshd 17 2.4 Configuration of PAM Modules 20 pam_env.conf 20 • pam_mount.conf.xml 21 • limits.conf 21 2.5 Configuring PAM Using pam-config 21 2.6 Manually Configuring PAM 22 2.7 For More Information 23 3 Using NIS 24 3.1 Configuring NIS Servers 24 Configuring a NIS Master Server 24 • Configuring a NIS Slave Server 29 3.2 Configuring NIS Clients 30 iii Security Guide 4 Authentication Server and Client 32 4.1 Configuring an Authentication Server with YaST 32 Initial Configuration of an Authentication Server 32 • Editing an Authentication Server Configuration with YaST 36 • Editing LDAP Users and Groups 41 4.2 Configuring an Authentication Client with YaST (SSSD) 41 5 LDAP—A Directory Service 46 5.1 LDAP versus NIS 47 5.2 Structure of an LDAP Directory Tree 47 5.3 Configuring LDAP Users and Groups in YaST 50 5.4 Manually Configuring an LDAP Server 51 Starting and Stopping the Servers 52 5.5 Manually Administering LDAP Data 52 Inserting Data into an LDAP Directory 52 • Modifying Data in the LDAP Directory 54 • Searching or Reading Data from an LDAP Directory 55 • Deleting Data from an LDAP Directory 55 5.6 For More Information 56 6 Active Directory Support 57 6.1 Integrating Linux and AD Environments 57 6.2 Background Information for Linux AD Support 58 Domain Join 60 • Domain Login and User Homes 61 • Offline Service and Policy Support 62 6.3 Configuring a Linux Client for Active Directory 63 6.4 Logging In to an AD Domain 66 GDM 67 • Console Login 67 6.5 Changing Passwords 67 iv Security Guide 7 Network Authentication with Kerberos 69 7.1 Kerberos Terminology 69 7.2 How Kerberos Works 71 First Contact 71 • Requesting a Service 72 • Mutual Authentication 72 • Ticket Granting—Contacting All Servers 72 • Compatibility to Windows 2000 73 7.3 Users' View of Kerberos 74 7.4 Installing and Administering Kerberos 75 Kerberos Network Topology 76 • Choosing the Kerberos Realms 77 • Setting Up the KDC Hardware 77 • Configuring Time Synchronization 78 • Configuring the KDC 79 • Configuring Kerberos Clients 82 • Configuring Remote Kerberos Administration 85 • Creating Kerberos Service Principals 86 • Enabling PAM Support for Kerberos 88 • Configuring SSH for Kerberos Authentication 88 • Using LDAP and Kerberos 89 7.5 For More Information 92 II LOCAL SECURITY 93 8 Configuring Security Settings with YaST 94 8.1 Security Overview 94 8.2 Predefined Security Configurations 95 8.3 Password Settings 96 8.4 Boot Settings 96 8.5 Login Settings 97 8.6 User Addition 97 8.7 Miscellaneous Settings 97 v Security Guide 9 Authorization with PolKit 99 9.1 Conceptual Overview 99 Available Authentication Agents 99 • Structure of PolKit 99 • Available Commands 100 • Available Policies and Supported Applications 100 9.2 Authorization Types 102 Implicit Privileges 102 • Explicit Privileges 103 • Default Privileges 103 9.3 Querying Privileges 103 9.4 Modifying Configuration Files 104 Adding Action Rules 104 • Adding Authorization Rules 106 • Modifying Configuration Files for Implicit Privileges 106 9.5 Restoring the Default Privileges 107 10 Access Control Lists in Linux 109 10.1 Traditional File Permissions 109 The setuid Bit 109 • The setgid Bit 110 • The Sticky Bit 110 10.2 Advantages of ACLs 110 10.3 Definitions 111 10.4 Handling ACLs 112 ACL Entries and File Mode Permission Bits 113 • A Directory with an ACL 114 • A Directory with a Default ACL 116 • The ACL Check Algorithm 119 10.5 ACL Support in Applications 120 10.6 For More Information 120 11 Encrypting Partitions and Files 121 11.1 Setting Up an Encrypted File System with YaST 122 Creating an Encrypted Partition during Installation 122 • Creating an Encrypted Partition on a Running System 123 • Creating an Encrypted File as a Container 124 • Encrypting the Content of Removable Media 124 11.2 Using Encrypted Home Directories 125 vi Security Guide 11.3 Using vi to Encrypt Single ASCII Text Files 126 12 Certificate Store 127 12.1 Activating Certificate Store 127 12.2 Importing Certificates 127 13 Intrusion Detection with AIDE 129 13.1 Why Using AIDE? 129 13.2 Setting Up an AIDE Database 129 13.3 Local AIDE Checks 132 13.4 System Independent Checking 133 13.5 For More Information 134 III NETWORK SECURITY 135 14 SSH: Secure Network Operations 136 14.1 ssh—Secure Shell 136 Starting X Applications on a Remote Host 137 • Agent Forwarding 137 14.2 scp—Secure Copy 137 14.3 sftp—Secure File Transfer 138 Setting Permissions for File Uploads 139 14.4 The SSH Daemon (sshd) 140 14.5 SSH Authentication Mechanisms 141 Generating an SSH Key 142 • Copying an SSH Key 142 • Using the ssh- agent 143 14.6 Port Forwarding 144 14.7 For More Information 145 15 Masquerading and Firewalls 146 15.1 Packet Filtering with iptables 146 vii Security Guide 15.2 Masquerading Basics 149 15.3 Firewalling Basics 150 15.4 SuSEFirewall2 151 Configuring the Firewall with YaST 152 • Configuring Manually 155 15.5 For More Information 158 16 Configuring a VPN Server 159 16.1 Conceptual Overview 159 Terminology 159 • VPN Scenarios 160 16.2 Setting Up a Simple Test Scenario 163 Configuring the VPN Server 164 • Configuring the VPN Client 164 • Testing the VPN Example Scenario 165 16.3 Setting Up Your VPN Server Using Certificate Authority 165 Creating Certificates 166 • Configuring the Server 169 • Configuring the Clients 171 16.4 Changing Name Servers in VPN 172 16.5 The GNOME Applet 173 16.6 For More Information 174 17 Managing X.509 Certification 175 17.1 The Principles of Digital Certification 175 Key Authenticity 176 • X.509 Certificates 176 • Blocking X.509 Certificates 177 • Repository for Certificates and CRLs 178 • Proprietary PKI 179 17.2 YaST Modules for CA Management 179 Creating a Root CA 179 • Changing Password 181 • Creating or Revoking a Sub-CA 182 • Creating or Revoking User Certificates 184 • Changing Default Values 185 • Creating Certificate Revocation Lists (CRLs) 186 • Exporting CA Objects to LDAP 187 • Exporting CA Objects as a File 188 • Importing Common Server Certificates 189 viii Security Guide IV CONFINING PRIVILEGES WITH APPARMOR 190 18 Introducing AppArmor 191 18.1 Background Information on AppArmor Profiling 192 19 Getting Started 193 19.1 Installing AppArmor 193 19.2 Enabling and Disabling AppArmor 194 19.3 Choosing Applications to Profile 195 19.4 Building and Modifying Profiles 195 19.5 Updating Your Profiles 197 20 Immunizing Programs 198 20.1 Introducing the AppArmor Framework 199 20.2 Determining Programs to Immunize 201 20.3 Immunizing cron Jobs 202 20.4 Immunizing Network Applications 202 Immunizing Web Applications 204 • Immunizing Network Agents 206 21 Profile Components and Syntax 207 21.1 Breaking an AppArmor Profile into Its Parts 208 21.2 Profile Types 210 Standard Profiles 210 • Unattached Profiles 211 • Local Profiles 211 • Hats 212 • Change rules 212 21.3 Include Statements 213 Abstractions 215 • Program Chunks 215 • Tunables 215 21.4 Capability Entries (POSIX.1e) 215 21.5 Network Access Control 216 ix Security Guide 21.6 Profile Names, Flags, Paths, and Globbing 217 Profile Flags 218 • Using Variables in Profiles 219 • Pattern Matching 220 • Namespaces 221 • Profile Naming and Attachment Specification 221 • Alias Rules 222 21.7 File Permission Access Modes 222 Read Mode (r) 223 • Write Mode (w) 223 • Append Mode (a) 223 • File Locking Mode (k) 223 • Link Mode (l) 224 • Link Pair 224 • Optional allow and file Rules 224 • Owner Conditional Rules 225 • Deny Rules 226 21.8 Execute Modes 226 Discrete Profile Execute Mode (Px) 227 • Discrete Local Profile Execute Mode (Cx) 227 • Unconfined Execute Mode (Ux) 227 • Unsafe Exec Modes 228 • Inherit Execute Mode (ix) 228 • Allow Executable Mapping (m) 228 • Named Profile Transitions 228 • Fallbacks for Profile Transitions 229 • Variable Settings in Execution Modes 230 • safe and unsafe Keywords 231
Load more

Recommended publications
  • (Un)Smashing the Stack
    Hello, Interwebs Hi, and thanks for reading this. As I mentioned a number of times during the talk this was one long, hard slog of a topic for me. My intent was not to duplicate existing research (Johnson and Silberman @ BHUS05, others), but to try to make this topic comprehensible for the typical security professional, who (GASP! SHOCK! HORROR!) may not necessarily grasp all the hairy internals of exploit development, but still is tasked with protecting systems. For the other 90% of us out there, our job is not to be leet, but rather not to get owned, something I hope to get a little bit better at every day. Since exploit mitigation is something that might bring us all a little bit closer to that, I wanted to explore the topic. Thanks much to BH for giving me the opportunity to do so, and to all of you for listening. Thanks also to all the amazing people working on these technologies, especially the PaX team and Hiroaki Etoh of IBM. -- shawn P.S. It’s actually Thompson that had the Phil Collins hair, not Ritchie. Sorry, Dennis. 28 75 6e 29 53 6d 61 73 68 69 6e 67 20 74 68 65 20 53 74 61 63 6b 0d 0a (un)Smashing the Stack 4f 76 65 72 66 6c 6f 77 73 2c 20 43 6f 75 6e 74 65 72 6d 65 61 73 75 72 65 73 20 61 6e 64 20 74 68 65 20 52 65 61 6c 20 57 6f 72 6c 64 Overflows, Countermeasures and the Real World Shawn Moyer :: Chief Researcher ---- SpearTip Technologies ---> blackhat [at] cipherpunx [dot] org Hey, who is this guy? ShawnM: InfoSec consultant, (quasi-) developer, husband, father, and raging paranoid with obsessive tendencies Chief Researcher at SpearTip Technologies Security Consultancy in Saint Louis, MO Forensics, Assessment, MSSP, network analysis Weddings, Funerals, Bar Mitzvahs I like unsolvable problems, so I’m mostly interested in defense.
    [Show full text]
  • Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
    Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian
    [Show full text]
  • On the Quality of Exploit Code
    On the Quality of Exploit Code An Evaluation of Publicly Available Exploit Code, Hackers & Threats II, February 17, 2:00 PM, San Francisco, CA Ivan Arce, Core Security Technologies OUTLINE • Prologue: Context and definitions • Why exploit code? • Quality metrics • Examples • Epilogue: Future work PROLOGUE VULNERABILITIES & EXPLOITS Lets start by defining a common language • Vulnerability (noun) — “A flaw in a system that, if leveraged by an attacker, can potentially impact the security of said system” — Also: security bug, security flaw, security hole • Exploit (verb) — “To use or manipulate to one’s advantage” (Webster) — “A security hole or an instance of taking advantage of a security hole” EXPLOIT CODE Exploit code is not just “proof of concept” • Proof of Concept exploit - PoC (noun) — A software program or tool that exploits a vulnerability with the sole purpose of proving its existence. • Exploit Code (noun) — A software program or tool developed to exploit a vulnerability in order to accomplish a specific goal. — Possible goals: denial of service, arbitrary execution of code, etc An emerging role in the information security practice WHY TALK ABOUT EXPLOIT CODE? ANATOMY OF A REAL WORLD ATTACK The classic attack uses exploit code... ATTACKER Base Camp A target server is attacked and compromised The acquired server is used as vantage point to penetrate the corporate net Further attacks are performed as an internal user EXPLOIT CODE FUNCTIONALITY Exploit code becomes more sophisticated • Add a simple “listen shell” echo "ingreslock stream tcp nowait root /bin/sh sh -i" >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob &" • Add an account to the compromised system: echo "sys3:x:0:103::/:/bin/sh" >> /etc/passwd; echo "sys3:1WXmkX74Ws8fX/MFI3.j5HKahNqIQ0:12311:0:99999:7:::" >> /etc/shadow • Execute a “bind-shell” • Execute a “reverse shell” • Deploy and execute a multi-purpose agent Command shell, FTP, TFTP, IRC, “zombies”, snifers, rootkits..
    [Show full text]
  • Seth Arnold SARNOLD(7)
    SARNOLD(7) Seth Arnold SARNOLD(7) NAME Seth Arnold - sarnold(7) - +1-503-577-3453 - [email protected] SYNOPSIS I am versatile, able to quickly adapt to and excel in complex systems, especially those with subtle security and reliability problems. I enjoy talking with customers and users; my most recent supervisor noted I have a very good sense of the customer's voice. I support co-workers with enthusiasm, improving a team's productivity and morale. OPTIONS · 15 years experience developing software for Linux (Ubuntu, Debian, SuSE, Red Hat, Slackware, Caldera). · 6 years experience using OpenBSD, WinNT 4.0 / Win2K. · 4 years experience using NetWare 3.11, SCO 3.2.4.2, and SCO OpenServer 5.0. · Programming Languages: C, Ruby, Perl, Python, Java, Unix shell, SQL, HTML, LaTeX · Source code control systems: Git, Subversion, CVS, BitKeeper · Native English speaker; learning German I have expertise with Linux kernel internals, cryptography, security issues, software development and mainte- nance, and the TCP/IP family of protocols. I am familiar with the constraints and freedoms of open source licenses. I give confident, credible, and effective presentations about complex subjects. I participate in Free Software and Open Source communities. I have been part of the Open and Free Technology Community's NOC and a staff member on Freenode. HISTORY May 2005 { October 2007 Novell, Inc. / SuSE GmbH; Portland, OR, USA I joined the SuSE Labs research and development team when Novell acquired Immunix. My responsibilities at Novell / SuSE included: Software development Primary developer of AppArmor Mandatory Access Control policies for the SuSE Linux family of distribu- tions.
    [Show full text]
  • A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors
    A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors Ramkumar Chinchani and Shambhu Upadhyaya Kevin Kwiat Dept. of Computer Science and Engineering Air Force Research Laboratory University at Buffalo, SUNY 525 Brooks Road Amherst, NY 14260 Rome, NY 13441 Email: rc27, shambhu ¡ @cse.buffalo.edu Email: [email protected] Abstract with large projects [14], [9], [12], [11] suggest this. Maintaining high availability of these services is criti- Replication and redundancy techniques rely on the as- cal for the smooth functioning of any organization relying sumption that a majority of components are always safe and on those resources. These services can fail due to software voting is used to resolve any ambiguities. This assumption faults or attacks by intruders. Occurrence of faults can result may be unreasonable in the context of attacks and intru- in the unpredictable failure of the system. Intrusions are of- sions. An intruder could compromise any number of the ten likened to faults and successful attacks, like faults, leave available copies of a service resulting in a false sense of the system in an inconsistent or unusable state. security. The kernel based approaches have proven to be Fault detection and tolerance techniques have goals such quite effective but they cause performance impacts if any as dependability, reliability, availability, safety and per- code changes are in the critical path. In this paper, we pro- formability which are similar to the goals of intrusion pre- vide an alternate user space mechanism consisting of pro- vention and detection, and other security measures. How- cess monitors by which such user space daemons can be ever, the correspondence is not always one to one.
    [Show full text]
  • GNU/Linux Distro Timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A
    1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 Libranet Omoikane (Arma) Gibraltar GNU/Linux distro timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A. Lundqvist, D. Rodic - futurist.se/gldt Freespire Published under the GNU Free Documentation License MEPIS SimplyMEPIS Impi Guadalinex Clonezilla Live Edubuntu Xubuntu gNewSense Geubuntu OpenGEU Fluxbuntu Eeebuntu Aurora OS Zebuntu ZevenOS Maryan Qimo wattOS Element Jolicloud Ubuntu Netrunner Ylmf Lubuntu eBox Zentyal Ubuntu eee Easy Peasy CrunchBang gOS Kiwi Ubuntulite U-lite Linux Mint nUbuntu Kubuntu Ulteo MoLinux BlankOn Elive OS2005 Maemo Epidemic sidux PelicanHPC Inquisitor Canaima Debian Metamorphose Estrella Roja BOSS PureOS NepaLinux Tuquito Trisquel Resulinux BeatriX grml DeadCD Olive Bluewall ASLinux gnuLiNex DeMuDi Progeny Quantian DSL-N Damn Small Linux Hikarunix Damn Vulnerable Linux Danix Parsix Kanotix Auditor Security Linux Backtrack Bioknoppix Whoppix WHAX Symphony OS Knoppix Musix ParallelKnoppix Kaella Shabdix Feather KnoppMyth Aquamorph Dreamlinux Morphix ZoneCD Hiwix Hiweed Deepin Kalango Kurumin Poseidon Dizinha NeoDizinha Patinho Faminto Finnix Storm Corel Xandros Moblin MeeGo Bogus Trans-Ameritech Android Mini Monkey Tinfoil Hat Tiny Core Yggdrasil Linux Universe Midori Quirky TAMU DILINUX DOSLINUX Mamona Craftworks BluePoint Yoper MCC Interim Pardus Xdenu EnGarde Puppy Macpup SmoothWall GPL SmoothWall Express IPCop IPFire Beehive Paldo Source Mage Sorcerer Lunar eIT easyLinux GoboLinux GeeXboX Dragora
    [Show full text]
  • Meeting Critical Security Objectives with Security-Enhanced Linux
    Meeting Critical Security Objectives with Security-Enhanced Linux Peter A. Loscocco Information Assurance Research Group National Security Agency Co-author: Stephen D. Smalley, NAI Labs ■ Information Assurance Research Group ■ 1 Presentation Outline • Operating system security • The Flask architecture • Security-enhanced Linux • Example security server • Meeting critical security objectives • Future Direction ■ Information Assurance Research Group ■ 2 The Need for Secure OS • Increasing risk to valuable information • Dependence on OS protection mechanisms • Inadequacy of mainstream operating systems • Key missing feature: Mandatory Access Control (MAC) – Administratively-set security policy – Control over all subjects and objects in system – Decisions based on all security-relevant information ■ Information Assurance Research Group ■ 3 Why is DAC inadequate? • Decisions are only based on user identity and ownership • No protection against malicious software • Each user has complete discretion over his objects • Only two major categories of users: superuser and other • Many system services and privileged programs must run with coarse-grained privileges if not as superuser ■ Information Assurance Research Group ■ 4 What can MAC offer? • Strong separation of security domains • System and data integrity • Ability to limit program privileges • Protection against tamper and bypass • Processing pipelines guarantees • Authorization limits for legitimate users ■ Information Assurance Research Group ■ 5 MAC Implementation Issues • Must overcome
    [Show full text]
  • Counterpoint
    COVER STORY AppArmor vs. SELinux Novell and Red Hat security experts face off on AppArmor and SELinux COUNTERPOINT www.photocase.com Security Enhanced Linux or App Armor? Linux Magazine invited two well-known per- sonalities from Red Hat and Novell to debate the merits of their security systems. BY ACHIM LEITNER ovell and Red Hat are currently complexity of the resulting software. The doing battle to establish their re- Crispin Cowan, Novell Strict Policy that SELinux first provided Nspective products as competitive AppArmor[1] and SELinux have similar was found to be too strict to be usable, protection systems for Linux. Whereas goals of improving Linux security, but and so SELinux actively moved towards Red Hat adopted SELinux years ago, No- the goals differ in detail. AppArmor se- the AppArmor model with the Targeted vell introduced their AppArmor protec- cures individual applications against la- Policy, which simulates AppArmor’s tion system after acquiring Immunix. tent defects, and pro- Both systems are licensed under the tects an entire system Figure 1: Crispin Cowan: GPL, both aim to make Linux more se- against a particular “Simplicity is the soul of cure, and both give administrators more threat such as network security…SELinux seems to control over applications privileges. attack, by protecting all have been designed to meet We asked spokesmen from Novell and applications that face the NSA’s desire for arbi- Red Hat to explain why their security the network. SELinux trarily complex policy at the system is the best. Crispin Cowan, who instead sought to con- expense of usability…App- came to Novell from Immunix, will be trol the whole system, Armor was designed for talking first about the advantages of including assuring usability – to meet the needs AppArmor.
    [Show full text]
  • Sandboxing in Linux: from Smartphone to Cloud
    International Journal of Computer Applications (0975 - 8887) Volume 148 - No.8, August 2016 Sandboxing in Linux: From Smartphone to Cloud Imamjafar Borate R. K. Chavan CSE Department CSE Department SGGSIE&T Nanded SGGSIE&T Nanded India India ABSTRACT Desktops and Cloud Systems. [28, 55, 32] Traditional operating system security features provide security from most of the threats. In today’s internet world, Malicious and malfunctioning contents However, we need to add some extra defense to our systems. Sand- from the internet are regular problems for host systems such as boxing is an important security mechanism that lets programs and Smartphones, Desktops, Clouds etc. Almost all underlying oper- processes run in its isolated environment. Sandbox isolate running ating systems provide security from most of the threats. However, the program from host operating system and other running pro- we need to add some extra defense to our system. Sandboxing is grams on the system. Sandbox is an environment where the pro- an important security technique that lets programs run in its iso- gram can only access restricted set of resources. It is a way to re- lated environment. A sandbox is a tightly controlled environment strict a program’s ability to access resources. It is different from where programs run. It provides access to a tightly controlled set access control applied to running processes. Typically sandboxes of resources for programs, such as memory, scratch space on the only apply to programs explicitly launched into a sandbox, where disk, network access, and input devices. A program running in the as traditional access control methods apply to all programs.[34, 46] sandbox has just as many permissions as it needs without having The sandboxing is based on prevention instead of detection in the additional permissions that could be misused.
    [Show full text]
  • Security Guide Opensuse Leap 42.3 Security Guide Opensuse Leap 42.3
    Security Guide openSUSE Leap 42.3 Security Guide openSUSE Leap 42.3 Introduces basic concepts of system security, covering both local and network secu- rity aspects. Shows how to use the product inherent security software like AppAr- mor or the auditing system that reliably collects information about any security-rel- evant events. Publication Date: November 05, 2018 SUSE LLC 10 Canal Park Drive Suite 200 Cambridge MA 02141 USA https://www.suse.com/documentation Copyright © 2006– 2018 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu- mentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third-party trademarks are the prop- erty of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xv 1 Security and Confidentiality 1 1.1 Local Security and Network Security 1 Local Security 3 • Network Security 6
    [Show full text]
  • Securing Your System with Apparmor & Selinux
    Securing your system with AppArmor & SELinux Johannes Segitz SUSE Security Team 2014/11/27 Introduction What will we cover? • Mandatory access control • AppArmor • SELinux • Comparison 50 minutes are not much time, so: • Mix between concrete examples and higher level concepts • Complex systems, some statements are simpler than the reality 3 of 41 Who am I? • SUSE employee since 2014, security engineer, resident in Germany • Long time interest in IT security • Long time fan of mandatory access control systems (Rule Set Based Access Control - RSBAC, 1998) • First time in Stockholm, very nice city 4 of 41 Mandatory access control Discretionary access control (DAC) Usual form of access control in Linux • Typical example: # ls -l /etc/shadow -rw-r-----. 1 root shadow 1421 /etc/shadow • Discretionary: The owner of an object can control the access of the objects he owns 6 of 41 Discretionary access control (DAC) Drawbacks: • Coarse: Basically 3 x rwx • Prone to (user) error # ls -lah ~/.ssh/id_rsa -rw-rw-rw-. 1 jsegitz users 1.7K ~/.ssh/id_rsa • Hard to analyze • root == God (- capabilities) But it's familiar, easy to use and to understand 7 of 41 Mandatory access control (MAC) Mandatory (in this context): • Access control decisions are not made by the owner/user • Access control rules are managed centrally Advantages: • Access control in the hand of people who know what they're doing • Centralized control and review is possible • Often very fine grained ! compartmentalization Drawbacks: • (Sometimes) hard to understand • (Sometimes) complex to
    [Show full text]
  • Linux Security Module Framework
    Linux Security Module Framework Chris Wright and Crispin Cowan ∗ Stephen Smalley † WireX Communications, Inc. NAI Labs, Network Associates, Inc. [email protected], [email protected] [email protected] James Morris Greg Kroah-Hartman Intercode Pty Ltd IBM Linux Technology Center [email protected] [email protected] Abstract 1 Introduction Security is a chronic and growing problem: as more Computer security is a chronic and growing prob- systems (and more money) go on line, the motiva- lem, even for Linux, as evidenced by the seem- tion to attack rises. Linux is not immune to this ingly endless stream of software security vulnera- threat: the “many eyes make shallow bugs” argu- bilities. Security research has produced numerous ment [24] not withstanding, Linux systems do expe- access control mechanisms that help improve sys- rience a large number of software vulnerabilities. tem security; however, there is little concensus on the best solution. Many powerful security systems An important way to mitigate software vulnera- have been implemented as research prototypes or bilities is through effective use of access controls. highly specialized products, leaving systems opera- Discretionary access controls (root, user-IDs and tors with a difficult challenge: how to utilize these mode bits) are adequate for user management of advanced features, without having to throw away their own privacy, but are not sufficient to pro- their existing systems? tect systems from attack. Extensive research in non-discretionary access control models has been The Linux Security Modules (LSM) project ad- done for over thirty years [1, 25, 17, 9, 15, 4, 19] dresses this problem by providing the Linux kernel but there has been no real consensus on which with a general purpose framework for access control.
    [Show full text]