Vsys: a Programmable Sudo
Total Page:16
File Type:pdf, Size:1020Kb

Load more
Recommended publications
-
A Practical UNIX Capability System
A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability . -
Beej's Guide to Unix IPC
Beej's Guide to Unix IPC Brian “Beej Jorgensen” Hall [email protected] Version 1.1.3 December 1, 2015 Copyright © 2015 Brian “Beej Jorgensen” Hall This guide is written in XML using the vim editor on a Slackware Linux box loaded with GNU tools. The cover “art” and diagrams are produced with Inkscape. The XML is converted into HTML and XSL-FO by custom Python scripts. The XSL-FO output is then munged by Apache FOP to produce PDF documents, using Liberation fonts. The toolchain is composed of 100% Free and Open Source Software. Unless otherwise mutually agreed by the parties in writing, the author offers the work as-is and makes no representations or warranties of any kind concerning the work, express, implied, statutory or otherwise, including, without limitation, warranties of title, merchantibility, fitness for a particular purpose, noninfringement, or the absence of latent or other defects, accuracy, or the presence of absence of errors, whether or not discoverable. Except to the extent required by applicable law, in no event will the author be liable to you on any legal theory for any special, incidental, consequential, punitive or exemplary damages arising out of the use of the work, even if the author has been advised of the possibility of such damages. This document is freely distributable under the terms of the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See the Copyright and Distribution section for details. Copyright © 2015 Brian “Beej Jorgensen” Hall Contents 1. Intro................................................................................................................................................................1 1.1. Audience 1 1.2. Platform and Compiler 1 1.3. -
Linux Hacking Case Studies Part 4: Sudo Horror Stories
Linux Hacking Case Studies Part 4: Sudo Horror Stories written by Scott Sutherland | March 26, 2020 This blog will cover different ways to approach SSH password guessing and attacking sudo applications to gain a root shell on a Linux system. This case study commonly makes appearances in CTFs, but the general approach for attacking weak passwords and sudo applications can be applied to many real world environments. This should be a fun walk through for people new to penetration testing. This is the fourth of a five part blog series highlighting entry points and local privilege escalation paths commonly found on Linux systems during network penetration tests. Below are links to the first three blogs in the series: Linux Hacking Case Study Part 1: Rsync Linux Hacking Case Study Part 2: NFS Linux Hacking Case Study Part 3: phpMyAdmin Below is an overview of what will be covered in this blog: Finding SSH Servers Dictionary Attacks against SSH Servers Viewing Sudoers Execution Options Exploiting Sudo sh Exploiting Sudo VI Exploiting Sudo Python Exploiting Sudo Nmap Finding SSH Servers Before we can start password guessing or attacking sudo applications, we need to find some SSH servers to go after. Luckily Nmap and similar port scanning tools make that pretty easy because most vendors still run SSH on the default port of 22. Below is a sample Nmap command and screenshot to get you started. nmap -sS -sV -p22 192.168.1.0/24 -oA sshscan Once you’ve run the port scan you can quickly parse the results to make a file containing a list of SSH servers to target. -
Getty Scholars' Workspace™ INSTALLATION INSTRUCTIONS
Getty Scholars’ Workspace™ INSTALLATION INSTRUCTIONS This document outlines methods to run the application locally on your personal computer or to do a full installation on a web server. Test Drive with Docker Getty Scholars' Workspace is a multi-tenant web application, so it is intended to be run on a web server. However, if you'd like to run it on your personal computer just to give it a test drive, you can use Docker to create a virtual server environment and run the Workspace locally. Follow the steps below to give it a spin. Scroll further for real deployment instructions. 1. Install Docker on your machine. Follow instructions on the Docker website: https://www.docker.com/ 2. If you are using Docker Machine (Mac or Windows), be sure to start it by using the Docker Quickstart Terminal. Docker is configured to use the default machine with IP 192.168.99.100. 3. At the command line, pull the Getty Scholars' Workspace image. $ docker pull thegetty/scholarsworkspace 4. Run the container. $ docker run -d -p 8080:80 --name=wkspc thegetty/scholarsworkspace supervisord -n 5. Point your browser to `<ip address>:8080/GettyScholarsWorkspace`. Use the IP address noted in Step 2. 6. The Drupal administrator login is `scholar` and the password is `workspace`. Be sure to change these in the Drupal admin interface. 7. To shut it down, stop the container: $ docker stop wkspc Web Server Installation These installation instructions assume you are installing Getty Scholars' Workspace on a server (virtual or physical) with a clean new instance of Ubuntu 14.04 as the operating system. -
Tao-Of-Tmux Documentation 发布 V1.0.2
tao-of-tmux Documentation 发布 v1.0.2 Tony Narlock 2020 年 04 月 18 日 Contents 1 前言 3 1.1 关于本书 ............................................... 3 1.2 代码等风格说明 ........................................... 4 1.3 本书主要内容 ............................................. 4 1.4 打赏 .................................................. 5 1.5 书籍形式(Formats) ........................................ 5 1.6 勘误说明(Errata){#errata} ................................... 5 1.7 感谢 .................................................. 6 1.8 本书跟新和 tmux 的变动 ...................................... 6 2 tmux 初识 {#thinking-tmux} 7 2.1 terminal 的窗口管理器 ....................................... 8 2.2 多任务处理 .............................................. 9 2.3 在后台运行程序 ........................................... 10 2.4 Powerful combos ........................................... 11 2.5 小节 .................................................. 12 3 Terminal 基础知识(fundamentals){#terminal-fundamentals} 13 3.1 POSIX 标准 ............................................. 13 3.2 Terminal interface .......................................... 14 3.3 Terminal emulators ......................................... 15 3.4 Shell languages {#shell-languages} ................................ 15 3.5 Shell interpreters (Shells) {#shells} ................................ 15 3.6 小节 .................................................. 16 4 开始使用(Practical usage){#practical-usage} 17 4.1 前缀组合快捷键(prefix key ){#prefix-key} ........................... 17 4.2 Session persistence and the server model ............................. 19 -
BSD UNIX Toolbox 1000+ Commands for Freebsd, Openbsd
76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page i BSD UNIX® TOOLBOX 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iv BSD UNIX® Toolbox: 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD® Power Users Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-37603-4 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data is available from the publisher. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permis- sion should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. -
Sockets in the Kernel
Linux Kernel Networking – advanced topics (6) Sockets in the kernel Rami Rosen [email protected] Haifux, August 2009 www.haifux.org All rights reserved. Linux Kernel Networking (6)- advanced topics ● Note: ● This lecture is a sequel to the following 5 lectures I gave in Haifux: 1) Linux Kernel Networking lecture – http://www.haifux.org/lectures/172/ – slides:http://www.haifux.org/lectures/172/netLec.pdf 2) Advanced Linux Kernel Networking - Neighboring Subsystem and IPSec lecture – http://www.haifux.org/lectures/180/ – slides:http://www.haifux.org/lectures/180/netLec2.pdf Linux Kernel Networking (6)- advanced topics 3) Advanced Linux Kernel Networking - IPv6 in the Linux Kernel lecture ● http://www.haifux.org/lectures/187/ – Slides: http://www.haifux.org/lectures/187/netLec3.pdf 4) Wireless in Linux http://www.haifux.org/lectures/206/ – Slides: http://www.haifux.org/lectures/206/wirelessLec.pdf 5) Sockets in the Linux Kernel ● http://www.haifux.org/lectures/217/ – Slides: http://www.haifux.org/lectures/217/netLec5.pdf Note ● Note: This is the second part of the “Sockets in the Linux Kernel” lecture which was given in Haifux in 27.7.09. You may find some background material for this lecture in its slides: ● http://www.haifux.org/lectures/217/netLec5.pdf TOC ● TOC: – RAW Sockets – UNIX Domain Sockets – Netlink sockets – SCTP sockets. – Appendices ● Note: All code examples in this lecture refer to the recent 2.6.30 version of the Linux kernel. RAW Sockets ● There are cases when there is no interface to create sockets of a certain protocol (ICMP protocol, NETLINK protocol) => use Raw sockets. -
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. -
Page 1 of 3 Sudo (Super User Do) Is a Very Useful
Sudo Sudo (Super User Do) is a very useful program that allows a system administrator to give certain users the ability to run some (or all) commands as root 1. Download the source code: The source of sudo is available from http://www.courtesan.com/sudo/. At the time of writing, the latest version is V1.6.3 and the source code is provided as a compressed tar archive in the file sudo- 1.6.3.tar.gz . Download this file to a temporary directory, such as /tmp. 2. Prepare the source code for compilation: Log in as root, make a directory at a convenient point in the file system to hold the source code and copy the source into this directory. For example: # mkdir -p /opt/source/sudo # cd /opt/source/sudo # cp /tmp/sudo-1.6.3.tar.gz . Unzip and untar the source and then change to the directory created by tar: # gunzip sudo # tar xvf sudo # cd sudo-1.6.3 At this point, you may like to have a look at the README, INSTALL and FAQ files. 3. Compile the source code and install sudo: Configure the compilation process for your system: # ./configure Compile the source code: # make And install the compiled code: # make install This install the sudo program into /usr/local/bin, the visudo script (see later) into /usr/local/sbin and the manual page into subdirectories of /usr/local/man. 4. Modify the search path: If you haven't already done so for other software, you now need to modify the search paths so that the system can find the sudo program and its manual pages. -
System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 15 SP1 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 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 Documentation 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 https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. 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 aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii -
Lab :: Snort (Ids)
LAB :: SNORT (IDS) # super user command. $ normal user command. Username apnic and password training . VM Details [group01.apnictraining.net] [192.168.30.1] [group02.apnictraining.net] [192.168.30.2] ...... [group10.apnictraining.net] [192.168.30.10] [group11.apnictraining.net] [192.168.30.11] ...... [group20.apnictraining.net] [192.168.30.20] [group21.apnictraining.net] [192.168.30.21] ...... [group30.apnictraining.net] [192.168.30.30] Install SNORT 1. Install SNORT: sudo apt update sudo apt install snort 2. It will ask for your HOME_NET address. For this lab define it as your host IP. Example, for group 11 it will 192.168.30.11/32 . If required we can change it later from snort.debian.conf file also. 3. Check the installation location of SNORT whereis snort Few important location SNORT configuration : /etc/snort/snort.conf SNORT debian configuration : /etc/snort/snort.debian.conf SNORT rules : /etc/snort/rules SNORT exuecuble : /usr/sbin/snort Configure SNORT 1. Check HOME_NET and Interface related configuration on /etc/snort/snort.debian.conf . During installation process if you had defined your HOME_NET properly; no need to edit it. Else, you can edit this file. 2. The main configuration file for SNORT is /etc/snort/snort.conf file. sudo vi /etc/snort/snort.conf This is a big configuration file; for the purpose of this lab we will disable all predefined rules (ruleset). Disable (comment out # ) all the line having include $RULE_PATH (in Step 7 of configuration file) except include $RULE_PATH/local.rules . We will put all our local rules in include $RULE_PATH/local.rules To enable alert log; comment out (adding # before the line) the following line (Step 6 in the configuration file): output unified2: filename snort.log, limit 128, nostamp, mpls_event_types, vlan_event_types Save and quit from snort.conf file :wq Start SNORT: sudo systemctl start snort or sudo /etc/init.d/snort start Check whether SNORT is running: sudo systemctl status snort or ps -ef|grep snort SNORT Rules Snort rules are divided into two logical sections: 1. -
Flatpak a Desktop Version of Containers
Flatpak a desktop version of containers Alexander Larsson, Red Hat What is Flatpak? A distribution-independent, Linux-based application distribution and deployment mechanism for desktop applications distribution-independent ● run on any distribution ● build on any distribution ● Any version of the distribution Linux-based ● Flatpak runs only on Linux ● Uses linux-specific features ● However, needs to run on older kernel ● Current minimum target – RHEL 7 – Ubuntu 16.04 (Xenial) – Debian 9 (Stretch) Distribution mechanism ● Built in support for install ● Built in support for updates ● Anyone can set up a repository Deployment mechanism ● Run apps in a controlled environment – “container” ● Sandbox for improved security – Default sandbox is very limited – Apps can ask for more permissions Desktop application ● Focus on GUI apps ● No root permissions ● Automatically integrates with desktop ● App lifetimes are ad-hoc and transient ● Nothing assumes a “sysadmin” being available How is flatpak different from containers Filesystem layout Docker requirements ● Examples: – REST API micro-service – Website back-end ● Few dependencies, all hand-picked ● Runs as a daemon user ● Writes to nonstandard locations in file-system ● Not a lot of integration with host – DNS – Port forwarding – Volumes for data ● No access to host filesystem ● Updates are managed Docker layout ● One image for the whole fs – Bring your own dependencies – Layout up to each app ● Independent of host filesystem layout Flatpak requirements ● Examples – Firefox – Spotify – gedit