DOCSLIB.ORG

Practical Techniques to Obviate Setuid-To-Root Binaries

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Practical Techniques to Obviate Setuid-To-Root Binaries Operating Systems, Security, Concurrency and Architecture Research Practical Techniques to Obviate Setuid-to-Root Binaries Bhushan Jain, Chia-Che Tsai, Jitin John, Donald Porter OSCAR Lab Computer Science Department Stony Brook University 1 Setuid-root and Privilege Escalaiton /bin/mount /dev/sda2 /disk1 Root Kernel 2 Setuid-root and Privilege Escalaiton /bin/mount /dev/sda2 /disk1 /* Parse arguments */ sys_mount(args); Root Kernel 3 Setuid-root and Privilege Escalaiton /bin/mount /dev/sda2 /disk1 /* Parse arguments */ sys_mount(args); Root root has all capabilities Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 4 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /* Parse arguments */ sys_mount(args); User user has no capabilities Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 5 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /* Parse arguments */ Setuid to Root sys_mount(args); User Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 6 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /* Parse arguments */ Setuid to Root sys_mount(args); User Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 7 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /dev/cdrom /cdrom iso9660 user,ro 0 0 /* Parse arguments */ Setuid /etc/fstab to Root sys_mount(args); User Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 8 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /dev/cdrom /cdrom iso9660 user,ro 0 0 /* Parse arguments */ Setuid /etc/fstab if(ruid == 0 || to Root user_mount_ok(args)) sys_mount(args); User Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 9 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /dev/cdrom /cdrom iso9660 user,ro 0 0 /* ParseExploit arguments */ Setuid if(ruid == 0 || to Root /etc/fstab Vulnerability */ user_mount_ok(args)) fd=open(“sys_mount(args);rootkit.ko”) finit_module(fd); User rootkit.ko Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 10 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /dev/cdrom /cdrom iso9660 user,ro 0 0 /* ParseExploit arguments */ Setuid if(ruid == 0 || to Root /etc/fstab Vulnerability */ user_mount_ok(args)) fd=open(“sys_mount(args);rootkit.ko”) finit_module(fd); User rootkit.ko Kernel sys_mount() { if(!capable(CAP_SYS_ADMIN)) return –EPERM; do_mount(); } 11 Setuid-root and Privilege Escalaiton /bin/mount /dev/cdrom /cdrom /dev/cdrom /cdrom iso9660 user,ro 0 0 /* ParseExploit arguments */ Setuid if(ruid == 0 || to Root /etc/fstab Vulnerability */ user_mount_ok(args)) fd=open(“sys_mount(args);rootkit.ko”) finit_module(fd); User rootkit.ko root has all capabilities Kernel sys_finit_modulesys_mount() { () { if(!capable(CAP_SYS_ADMIN))if(!capable(CAP_SYS_MODULE)) return –EPERM; rootkit.ko return –EPERM; do_mountdo_init_module(); } (); } 12 How is Setuid-Root Used in Practice? 100 80 26 Binaries on 60 89% systems 89% 40 83 Binaries on 20 <0.89% systems 0 Installation Percentage Installation 26 0 10 20 30 40 50 60 70 80 90 100 110 120 Setuid-to-Root Binaries 13 Can we get rid of setuid-to-root? Surprisingly feasible to obviate setuid-root . ~10 underlying privileged abstractions Protego prototype change 715 LoC in kernel . De-privileged 12,732 lines of trusted binary code . < 2% kernel compile time overhead over Linux 3.6.0 . Ongoing investigation of long tail 14 Outline Background Insights and design principles Protego overview and examples Evaluation 15 Linux Capabilities Linux file POSIX capabilities . Not same as pointers with access control . Divide root privilege into 36 different capabilities Enforce least privilege for administrator . Too coarse for untrusted user . Many privileged actions with just CAP_NET_ADMIN Need to think about least privilege for untrusted user 16 Efforts to Mitigate Setuid-Root Risks Ubuntu/Fedora try to limit use of setuid-root . Privilege Bracketing, consolidation, fs permissions . Not able to completely eliminate setuid-root Some binaries have point alternatives SELinux enforces relatively fine-grained security . Still too liberal for least privilege of user . SELinux introduces substantial complexity 17 What can we do about setuid-root risk? 18 How do we approach this problem? 100 Studied 28 in detail 80 . Order by popularity 60 40 Study policies in binaries 20 0 0 40 10 20 30 50 60 70 80 90 . Why is root needed? Percentage Installation 100 110 120 . Simpler alternative in kernel? Setuid-to-Root Binaries Goal: Non-admin never raises privilege 19 Setuid-Root: Unix Security Duct Tape Kernel policy mismatch with system policy . Kernel : only root can mount anywhere . System : any user can mount at safe locations Point solutions used as duct tape . Setuid binary mount bridges the gap Generally setuid patches kernel and system policies 20 Interface Designs can Thwart Least Privilege Interface design choice may need more privilege dmcrypt-get-device use privileged ioctl . Reports physical device under encrypted device . Also discloses the private key . Can get same info from /sys without privilege . Maintainers agreed to use /sys interface. Sometimes setuid indicates programmer error 21 Protego Design No need for trusted apps to enforce system policy . Inform kernel about system policy . Enforce system policy using Linux Security Module . Policies orthogonal to AppArmor, SELinux, etc. Object-based policies for unprivileged users Adjust the interfaces that need more privilege Maintain backwards compatibility for user 22 System Abstractions for Setuid Binaries Privileged Interface Used by What do we do? mount, umount 3 Whitelist safe locations and options socket (ping) 5 Apply firewall rules on raw sockets Credential databases (passwd) 5 Fragment to per-user or pergroup files, matching DAC granularity. ioctl (pppd) 2 Add LSM hooks to verify new routes bind (mail) 3 Map low port to (binary, userid) pair setuid, setgid (sudo) 7 Delegation Framework: LSM hooks to check delegation rules & recency Video driver control state (X) 1 Kernel Mode Switching: Context switches video devices in the kernel /dev/pts* terminal slaves (pt_chown) 1 Deprecated since kernel 2.1 Host private ssh key (ssh-keysign) 1 Restrict file access to specific binaries A few abstractions, many binaries 23 Example 1: Protego mount Root Kernel Protego LSM This technique works for 3/28 setuid-root binaries 24 Example 1: Protego mount /etc/fstab Root Kernel Protego LSM This technique works for 3/28 setuid-root binaries 25 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 /etc/fstab Root Kernel Protego LSM This technique works for 3/28 setuid-root binaries 26 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 /etc/fstab Privileged Daemon /*Parse /etc/fstab*/ Root Kernel Protego LSM This technique works for 3/28 setuid-root binaries 27 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 /etc/fstab Privileged Daemon /*Parse /etc/fstab*/ Root Kernel /proc/ mnt_policy Protego LSM This technique works for 3/28 setuid-root binaries 28 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 Unprivileged user /etc/fstab Privileged Daemon /*Parse /etc/fstab*/ Root Kernel /proc/ mnt_policy Protego LSM This technique works for 3/28 setuid-root binaries 29 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 Unprivileged user /etc/fstab Privileged Daemon mount /dev/cdrom /cdrom /*Parse /etc/fstab*/ Root Kernel /proc/ mnt_policy Protego LSM This technique works for 3/28 setuid-root binaries 30 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 Unprivileged user /etc/fstab Privileged Daemon mount /dev/cdrom /cdrom /*Parse /etc/fstab*/ sys_mount(args); Root Kernel /proc/ mnt_policy Protego LSM This technique works for 3/28 setuid-root binaries 31 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 Unprivileged user /etc/fstab Privileged Daemon mount /dev/cdrom /cdrom /*Parse /etc/fstab*/ sys_mount(args); Root sys_mount() { Kernel if(!security_mount_ok(args)) /proc/ return -EPERM; mnt_policy do_mount(args); Protego LSM } This technique works for 3/28 setuid-root binaries 32 Example 1: Protego mount /dev/cdrom /cdrom iso9660 user,ro 0 0 Unprivileged user /etc/fstab Privileged Daemon mount /dev/cdrom /cdrom /*Parse /etc/fstab*/ sys_mount(args); Root sys_mount() { Kernel if(!security_mount_ok(args)) /proc/ return -EPERM; mnt_policy do_mount(args); Protego LSM } This technique works for 3/28 setuid-root binaries 33 Underlying Problem with Setuid-bit Setuid bit is user/subject-based mechanism . “Does the user have privilege to take this action?” . E.g., Who can mount a device? Object-based security policies are better fit . “Can any user take an action on this object?” . E.g., Which device can be safely mounted and where? 34 Example 2: Linux ping Raw socket : unimplemented protocols in kernel TCP/UDP packets can be faked by raw sockets . Appear from socket owned by another process Kernel : CAP_NET_RAW to create raw socket System : Allow sending safe packets on raw socket . ping uses raw sockets for ICMP packets 35 Example 2: Protego ping Allow raw socket creation for all users Whitelist set of all safe packets on raw sockets . Use packet filtering framework (netfilter/BPF) . Limit raw socket protocol and message types For ping, allow ICMP echo request and reply This technique works for 5/28 setuid-root binaries 36 Example 3: Linux
Load more

Recommended publications
  • CSC 405 Computer Security Linux Security
    CSC 405 Computer Security Linux Security Alexandros Kapravelos [email protected] Unix / Linux • Started in 1969 at AT&T / Bell Labs • Split into a number of popular branches – BSD, System V (commercial, AT&T), Solaris, HP-UX, AIX • Inspired a number of Unix-like systems – Linux, Minix • Standardization attempts – POSIX, Single Unix Specification (SUS), Filesystem Hierarchy Standard (FHS), Linux Standard Base (LSB), ELF OS Security • Kernel vulnerability – usually leads to complete system compromise – attacks performed via system calls Kernel vulnerabilities Kernel vulnerabilities Kernel exploitation research is active Unleashing Use-Before-Initialization Vulnerabilities in the Linux Kernel Using Targeted Stack Spraying • reliably exploiting uninitialized uses on the kernel stack has been considered infeasible • code executed prior to triggering the vulnerability must leave an attacker-controlled pattern on the stack • a fully automated targeted stackspraying approach for the Linux kernel that reliably facilitates the exploitation of uninitialized uses • published in NDSS 2017 source: https://www.cc.gatech.edu/~klu38/publications/ubi-ndss17.pdf Unix • Code running in user mode is always linked to a certain identity – security checks and access control decisions are based on user identity • Unix is user-centric – no roles • User – identified by username (UID), group name (GID) – typically authenticated by password (stored encrypted) • User root – superuser, system administrator – special privileges (access resources, modify OS) – cannot
    [Show full text]
  • Environment Variable and Set-UID Program Lab 1
    SEED Labs – Environment Variable and Set-UID Program Lab 1 Environment Variable and Set-UID Program Lab Copyright © 2006 - 2016 Wenliang Du, All rights reserved. Free to use for non-commercial educational purposes. Commercial uses of the materials are prohibited. The SEED project was funded by multiple grants from the US National Science Foundation. 1 Overview The learning objective of this lab is for students to understand how environment variables affect program and system behaviors. Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. They are used by most operating systems, since they were introduced to Unix in 1979. Although environment variables affect program behaviors, how they achieve that is not well understood by many programmers. As a result, if a program uses environment variables, but the programmer does not know that they are used, the program may have vulnerabilities. In this lab, students will understand how environment variables work, how they are propagated from parent process to child, and how they affect system/program behaviors. We are particularly interested in how environment variables affect the behavior of Set-UID programs, which are usually privileged programs. This lab covers the following topics: • Environment variables • Set-UID programs • Securely invoke external programs • Capability leaking • Dynamic loader/linker Readings and videos. Detailed coverage of the Set-UID mechanism, environment variables, and their related security problems can be found in the following: • Chapters 1 and 2 of the SEED Book, Computer & Internet Security: A Hands-on Approach, 2nd Edition, by Wenliang Du.
    [Show full text]
  • SETUID Programming Due: February 15, 2017
    CSC 482/582 Assignment #3 (100 points) SETUID Programming Due: February 15, 2017 1 Introduction The learning objective of this assignment is for students to understand how environment variables affect program and system behaviors. Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. They are used by most operating systems, including Unix and Windows. Although environment variables affect program behaviors, how they achieve that is not well understood by many programmers. Therefore, if a program uses environment variables, but the programmer do not know that they are used, the program may have vulnerabilities. In this assignment, students will learn how environment variables work, how they are propogated from parent process to child, and how they affect system/program bahivors. We are particularly interested in how environment variables affect the behavior of SETUID programs, which are usually privileged programs. SETUID is an important security mechanism in Unix operating systems. When a regular program is run, it runs with the privilege of the user executing that program. When a SETUID program is run, it runs with the privilege of the program file owner. For example, if the program’s owner is root, then when anyone runs this program, the program gains root’s privileges during its execution. SETUID allows us to perform essential tasks, such as changing passwords, but vulnerabilities in SETUID programs can allow an adversary to perform local privilege escalation. While the SETUID concept is limited to Unix, the problems of dangerous environment variables and local privilege escalation exists on all operating systems.
    [Show full text]
  • Least Privilege and Privilege Separation
    CSE 127: Computer Security Least privilege and privilege separation Deian Stefan Slides adopted from John Mitchell, Dan Boneh, and Stefan Savage This week… • How to build secure systems ➤ Least privilege and privilege separation ➤ Sandboxing and isolation • Key is underlying principles not mechanisms ➤ We’re going to look at systems techniques ➤ Other ways to achieve similar goals: language-based Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource What’s the problem with this defn? • Talking about a huge, monolith system is not really useful • Why? Network Network User input User device File system File system Breaking a system into components • Compartmentalization and isolation ➤ Separate the system into isolated compartments ➤ Limit interaction between compartments • Why is this more meaningful? Network Network User input User device File system File system How dow we break things apart? Map compartment to user ids! • Recall: permissions in UNIX granted according to UID ➤ A process may access files, network sockets, ….
    [Show full text]
  • Linux Networking Cookbook.Pdf
    Linux Networking Cookbook ™ Carla Schroder Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Linux Networking Cookbook™ by Carla Schroder Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mike Loukides Indexer: John Bickelhaupt Production Editor: Sumita Mukherji Cover Designer: Karen Montgomery Copyeditor: Derek Di Matteo Interior Designer: David Futato Proofreader: Sumita Mukherji Illustrator: Jessamyn Read Printing History: November 2007: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Cookbook series designations, Linux Networking Cookbook, the image of a female blacksmith, and related trade dress are trademarks of O’Reilly Media, Inc. Java™ is a trademark of Sun Microsystems, Inc. .NET is a registered trademark of Microsoft Corporation. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Secure Automation: Achieving Least Privilege with SSH, Sudo and Setuid Robert A
    Secure Automation: Achieving Least Privilege with SSH, Sudo and Setuid Robert A. Napier – Cisco Systems ABSTRACT Automation tools commonly require some level of escalated privilege in order to perform their functions, often including escalated privileges on remote machines. To achieve this, developers may choose to provide their tools with wide-ranging privileges on many machines rather than providing just the privileges required. For example, tools may be made setuid root, granting them full root privileges for their entire run. Administrators may also be tempted to create unrestricted, null-password, root-access SSH keys for their tools, creating trust relationships that can be abused by attackers. Most of all, with the complexity of today’s environments, it becomes harder for administrators to understand the far-reaching security implications of the privileges they grant their tools. In this paper we will discuss the principle of least privilege and its importance to the overall security of an environment. We will cover simple attacks against SSH, sudo and setuid and how to reduce the need for root-setuid using other techniques such as non-root setuid, setgid scripts and directories, sudo and sticky bits. We will demonstrate how to properly limit sudo access both for administrators and tools. Finally we will introduce several SSH techniques to greatly limit the risk of abuse including non-root keys, command keys and other key restrictions. Introduction to files writable only by a particular group. For exam- ple, in FreeBSD programs that read system memory Since its introduction in 1995 by Tatu Ylonen, are setgid to a special kmem group.
    [Show full text]
  • Real-Time Audio Servers on BSD Unix Derivatives
    Juha Erkkilä Real-Time Audio Servers on BSD Unix Derivatives Master's Thesis in Information Technology June 17, 2005 University of Jyväskylä Department of Mathematical Information Technology Jyväskylä Author: Juha Erkkilä Contact information: [email protected].fi Title: Real-Time Audio Servers on BSD Unix Derivatives Työn nimi: Reaaliaikaiset äänipalvelinsovellukset BSD Unix -johdannaisjärjestelmissä Project: Master's Thesis in Information Technology Page count: 146 Abstract: This paper covers real-time and interprocess communication features of 4.4BSD Unix derived operating systems, and especially their applicability for real- time audio servers. The research ground of bringing real-time properties to tradi- tional Unix operating systems (such as 4.4BSD) is covered. Included are some design ideas used in BSD-variants, such as using multithreaded kernels, and schedulers that can provide real-time guarantees to processes. Factors affecting the design of real- time audio servers are considered, especially the suitability of various interprocess communication facilities as mechanisms to pass audio data between applications. To test these mechanisms on a real operating system, an audio server and a client utilizing these techniques is written and tested on an OpenBSD operating system. The performance of the audio server and OpenBSD is analyzed, with attempts to identify some bottlenecks of real-time operation in the OpenBSD system. Suomenkielinen tiivistelmä: Tämä tutkielma kattaa reaaliaikaisuus- ja prosessien väliset kommunikaatio-ominaisuudet, keskittyen 4.4BSD Unix -johdannaisiin käyt- töjärjestelmiin, ja erityisesti siihen kuinka hyvin nämä soveltuvat reaaliaikaisille äänipalvelinsovelluksille. Tutkimusalueeseen sisältyy reaaliaikaisuusominaisuuk- sien tuominen perinteisiin Unix-käyttöjärjestelmiin (kuten 4.4BSD:hen). Mukana on suunnitteluideoita, joita on käytetty joissakin BSD-varianteissa, kuten säikeis- tetyt kernelit, ja skedulerit, jotka voivat tarjota reaaliaikaisuustakeita prosesseille.
    [Show full text]
  • Introduction to Software Security
    PONG Introduction to software security Goals of this lab: ❖ Get practical experience with manual and automatic code review ❖ Get practical experience with basic exploit development ❖ Get practical experience with protection against exploits ❖ Get practical experience with repairing vulnerable code Prerequisites: A basic understanding of security in general REVISION: 1.97 [2020-11-09] ©2007-2020 DAVID BYERS;ULF KARGÉN TABLE OF CONTENTS Part 1: Using the Linux command line ....................................................................................................................................... 1 The shell .............................................................................................................................................................................................. 1 Paths ..................................................................................................................................................................................................... 1 Commands ......................................................................................................................................................................................... 2 Part 2: The QEMU lab environment ............................................................................................................................................ 4 Setting up the local image ..........................................................................................................................................................
    [Show full text]
  • OS Security Basics & Unix Access Control
    Information Security CS 526 Topic 8: Operating Systems Security Basics & Unix Access Control CS526 Topic 8: Operating System 1 Security Basics Readings for This Lecture • Wikipedia • CPU modes • System call • Filesystem Permissions • Other readings • UNIX File and Directory Permissions and Modes • http://www.hccfl.edu/pollock/A Unix1/FilePermissions.htm • Unix file permissions • http://www.unix.com/tips- tutorials/19060-unix-file- permissions.html CS526 Topic 8: Operating System 2 Security Basics Announcements and Outline • Outline of this topic – Brief overview of the goals of OS security – Memory protection, CPU modes, and system calls – Access control basic concepts – UNIX File System permissions – UNIX processes CS526 Topic 8: Operating System 3 Security Basics What Security Goals Does Operating System Provide? • Originally: time-sharing computers: enabling multiple users to securely share a computer – Separation and sharing of processes, memory, files, devices, etc. • What is the threat model? – Users may be malicious, users have terminal access to computers, software may be malicious/buggy, and so on • Security mechanisms – Memory protection – Processor modes – User authentication – File access control CS526 Topic 8: Operating System 4 Security Basics What Security Goals Does Operating System Provide? • More recent past and present: Networked desktop computers: ensure secure operation in networked environment • New threat? – Attackers coming from the network. Network-facing programs on computers may be buggy. Users may be hurt via online communication. • Security mechanisms – Authentication; Access Control – Secure Communication (using cryptography) – Logging & Auditing – Intrusion Prevention and Detection – Recovery CS526 Topic 8: Operating System 5 Security Basics What Security Goals Does Operating System Provide? • Present and near future: mobile computing devices: • New threat? – Apps (programs) may be malicious.
    [Show full text]
  • Singularity Container Documentation Release 2.5
    Singularity Container Documentation Release 2.5 Admin Docs Oct 17, 2018 CONTENTS 1 Administration QuickStart 1 1.1 Installation................................................1 1.1.1 Downloading the source....................................1 1.1.2 Source Installation.......................................1 1.1.3 Prefix in special places (–localstatedir).............................2 1.1.4 Building an RPM directly from the source...........................3 2 Security 5 2.1 Container security paradigms......................................5 2.2 Untrusted users running untrusted containers!..............................5 2.2.1 Privilege escalation is necessary for containerization!.....................5 2.2.2 How does Singularity do it?..................................6 2.3 Where are the Singularity priviledged components...........................6 2.4 Can I install Singularity as a user?....................................7 2.5 Container permissions and usage strategy................................7 2.5.1 controlling what kind of containers are allowed........................8 2.5.2 limiting usage to specific container file owners.........................8 2.5.3 limiting usage to specific paths.................................8 2.6 Logging..................................................9 2.6.1 A peek into the SetUID program flow............................. 10 2.6.2 A peek into the “rootless” program flow............................ 12 2.7 Summary................................................. 14 3 The Singularity Config File 15 3.1 Parameters...............................................
    [Show full text]
  • Set-UID Program Vulnerability Lab
    Laboratory for Computer Security Education 1 Set-UID Program Vulnerability Lab Copyright c 2006 - 2013 Wenliang Du, Syracuse University. � The development of this document is/was funded by three grants from the US National Science Foundation: Awards No. 0231122 and 0618680 from TUES/CCLI and Award No. 1017771 from Trustworthy Computing. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license can be found at http://www.gnu.org/licenses/fdl.html. Lab Description Set-UID is an important security mechanism in Unix operating systems. When a Set-UID program is run, it assumes the owner’s privileges. For example, if the program’s owner is root, then when anyone runs this program, the program gains the root’s privileges during its execution. Set-UID allows us to do many interesting things, but unfortunately, it is also the culprit of many bad things. Therefore, the objective of this lab is two-fold: (1) Appreciate its good side: understand why Set-UID is needed and how it is implemented. (2) Be aware of its bad side: understand its potential security problems. Lab Tasks This is an exploration lab. Your main task is to ”play” with the Set-UID mechanism in Linux, and write a lab report to describe your discoveries. You are required to accomplish the following tasks in Linux: 1. Figure out why "passwd", "chsh", "su", and "sudo" commands need to be Set-UID pro- grams.
    [Show full text]
  • Programming Assignment 4: Secure Password Programming Assigned: Tuesday, April 11, 2006 Due: Monday, May 8, Before 11:59 Pm
    COMP150ICS Spring 2006 PA #4 (Programming Assignment) Programming Assignment 4: Secure Password Programming Assigned: Tuesday, April 11, 2006 Due: Monday, May 8, before 11:59 pm Often in shared projects, we want to allow limited access to various resources based on a username/password pair. In this assignment, you will use this type of authentication to allow read access to a file in your home directory. To help you write a secure program, we will provide you with a static analysis tool to look for security flaws in your program. You will be graded on both the functionality and security of your program. The things you should take away from this assignment are: (1) a better understanding of UNIX permission-based security, (2) an introduction to secure programming, and (3) some experience with a static vulnerability scanning tool. Requirements: For this project, you will write a secure setuid program that will allow others to access a file that is only readable by your UNIX account. • Your program should be named “lockbox”. • It should read a username and password from a user who runs the program. This username and password are separate from the UNIX passwords on the system. They are specific to your program. • If the username/password combination is valid, print the contents of an existing file named “lockbox.txt”. • Your program will also log the usernames of everyone who accessed “lockbox.txt” in another file named “lockbox.log”. • Rather than have a single username/password for file access, you will have separate usernames/passwords that can be issued to different possible users.
    [Show full text]