DOCSLIB.ORG

Linux System Administration Course

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Linux system administration course Spring 2019: 2nd slideset 1 Booting a PC There are ancient and also brand new dragons here... 2 Starting a Linux PC ● PC firmware is started (BIOS or UEFI) ○ Devices are initialized and scanned: CPU, memory, devices, disks ○ Device controllers firmware initialization is run (network card, RAID controllers) ○ The boot device (disk or network device) is decided. ○ either by non-volatile firmware configuration or manually. ● The firmware loads and starts a boot loader from the boot device. ○ GNU Grub2 or Windows boot manager (there are others however) ○ Boot loader loads its configuration from disk or network. ○ Boot loader loads kernel and initial ramdisk (initrd) to memory. ● Boot loader starts Linux Kernel. ○ Kernel starts user space software on initrd ○ Initrd loads drivers and locates the OS system installation ● Initrd starts the Linux distribution Linux system administration, 2nd slide set © Jani Jaakkola 2019 3 Starting a Linux PC - TL;DR version 1. PC is powered on. 2. PC firmware is started. 3. Firmware locates boot device (network or disc). 4. Firmware load and starts boot loader (grub 2) from boot device. 5. Boot manager loads kernel and initial ramdisk. 6. Boot manager starts kernel. 7. Kernel starts software on initrd. 8. Initrd loads drivers. 9. Initrd mounts root filesystem. 10. Initrd starts /sbin/init (systemd) and is removed from memory. Linux system administration, 2nd slide set © Jani Jaakkola 2019 4 Legacy BIOS boot ● Legacy BIOS does not know how to use file systems. ○ It was invented in the 80’s. MS-DOS was the OS that had an actual file system. ● It can read the MBR (Master Boot Record) partition table. ● Boot loader (1st stage of it) is installed in known location in the MBR. ○ The boot loader is started from MBR in 16-bit non protected mode, just like MS-DOS ○ This is the only place left where 16-bit non protected mode is used in 2019. ○ There can be only one MBR boot loader on a given disk. ● The MBR partition table has a maximum size of 2T. ● … Amazingly, this system actually works. ○ Virtual machines are still mostly booted this way, even when PCs are not. Linux system administration, 2nd slide set © Jani Jaakkola 2019 5 UEFI boot ● BIOS boot was simple and worked. ○ Intel Itanium (RIP) needed a way to boot and didn’t have 16-bit real mode. ○ So new standard was required to make booting more complex (and buggy). ○ The need for 16-bit real mode got removed. This was nice. ● UEFI specification supports multiple architectures. ○ 32-bit Intel architecture and 64-bit Intel architecture and ARM architectures. ○ Forget the 32-bit Intel architecture: it wasn’t actually used, when 64 bit CPUs arrived. ● Has a standardised preboot execution environment with .EFI binaries. ○ Boot loaders are implemented as .EFI binaries. ○ Binaries can be loaded from a FAT partition on a disk or from network. ○ Support boot time applications (BIOS updates, hardware key management). ● GPT partition tables remove old MBR partition table limits. ○ No disc size limit. Linux system administration, 2nd slide set © Jani Jaakkola 2019 6 UEFI boot - Linux ● For Linux (and Windows) there needs to be a FAT32 formatted EFI partition. ○ This partition contains the bootable .EFI boot loader. ○ Usually mounted in /boot/efi ● The boot loader is installed in /boot/efi and is almost always Grub 2. ● UEFI has a nonvolatile memory storage for EFI variables. ○ These are used to configure the UEFI boot, including the selected boot loader. ○ These are managed with command line tool efibootmgr Linux system administration, 2nd slide set © Jani Jaakkola 2019 7 UEFI Secure boot ● UEFI binaries can be cryptographically signed. ● When secure boot is enabled, UEFI will verify signatures of binaries. ○ If the signature is not known, booting is refused. ○ Also, system will refuse to run anything unsigned in the kernel security ring. ○ The idea is to protect the system from malicious boot loaders and evil maids. ○ Typically the trusted signatures are from the vendor and MS and no one else. ○ This is a problem for open source and operating system development. ○ MS signs Linux boot loaders for Ubuntu and other commercial Linux platforms. ● Plain secure boot is just useless... ○ An attacker can always find a signed old binary containing security holes from the Internet. ○ If the disc is not encrypted, attacker just modifies the plain text parts of the operating system. ● Secure boot with TPM (Trusted Platform Module) can provide actual security. ○ Including validation that system isn’t modified and secure storage of disc encryption keys. Linux system administration, 2nd slide set © Jani Jaakkola 2019 8 Network boot ● During network boot the PC firmware queries the network for bootable image instead of a disc. ● The firmware configures the network with DHCP (Dynamic Host Configuration Protocol) and the booted image is selected with DHCP options. ● Legacy bios has PXE (pre boot execution environment) ○ Can boot Grub and PXELinux. ● UEFI boots normal *.EFI binaries ○ Which must be signed to use secure boot. Linux system administration, 2nd slide set © Jani Jaakkola 2019 9 Starting Linux Grub 2, initial ramdisk, systemd 10 Grub 2 Linux boot loader ● Grub 2 is the default boot loader of most Linux distributions ○ There are others, but most of them don’t work well with UEFI. ● Grub 2 supports legacy BIOS boot, Legacy network boot (pxe), UEFI boot, UEFI network and boot UEFI secure boot. ○ With different grub 2 binaries. ● Can provide an interactive boot menu. ● Has a programmable configuration file syntax. ● Has support for multiple Linux filesystems ○ Including virtual block devices, like logical volume management and RAID. ○ Can open and boot encrypted Linux partitions (rarely used however). ● Has a command line and an editor from on the fly modification of configuration Linux system administration, 2nd slide set © Jani Jaakkola 2019 11 Grub 2 boot process 1. Firmware starts the grub binary 2. Grub reads its configuration file grub.cfg 3. The configuration file provides a boot menu (if any) 4. A menu entry is booted: manually selected or default entry after a timeout. 5. Grub loads Linux kernel image specified in the menu entry to memory 6. Grub loads initrd specified in the menu entry to memory 7. Grub passes arguments to the kernel and starts it ● Kernel arguments can be read from /proc/cmdline Linux system administration, 2nd slide set © Jani Jaakkola 2019 12 Grub configuration and installation ● Grub is installed to a disk with the command grub-install <disk> ● Grub configuration /boot/grub/grub.cfg is normally automatically generated by the distribution. ○ Including the ability to boot to other OS like Windows, or other Linux installations. ○ You can write your own however. ● A new file is generated whenever there is a new kernel installed. ○ Or Grub is upgraded to a newer version. ● In Ubuntu and Debian this happens with the script update-grub ○ There are hooks to modify and add boot entries of your own. ● You need to modify grub configuration when: ○ You want to boot non distribution kernels or other operating systems. ○ You want to modify kernel boot arguments. Linux system administration, 2nd slide set © Jani Jaakkola 2019 13 Initial ramdisk - initrd ● Initrd is a small complete boot time Linux system. ○ It is loaded to memory by boot loader and then uncompressed and started by the Linux kernel. ● Initrd contains drivers and configuration for the installed system. ○ Initrd is specific to the system where it is started. ○ Only drivers which are needed during the boot are added to initrd. ■ Disc drivers, filesystem drivers, logical file system drivers. ● Can provide a splash screen when booting (with Plymouth scripting) ● Initrd scans the system and locates the root device directory / ○ Opening encrypted root file system is (usually) managed by initrd. ○ And the starts /sbin/init from the root file system ● After initrd has done its job, its memory is freed. ● Created with mkinitramfs (Ubuntu, Debian) or dracut (Red Hat) Linux system administration, 2nd slide set © Jani Jaakkola 2019 14 /sbin/init ● The first process to start in a Linux (and Unix) system is /sbin/init ○ Started right after initrd has mounted root filesystem and gone away. ● Init starts all the other daemons and configuration scripts needed for a working system. ○ Mount other file systems. ○ Start getty on virtual consoles and serial terminals to enable logins. ○ Start network configuration. ○ Start sshd. ○ ... ● Init always has process id (PID) 1. ○ Traditionally you communicated with init by sending signals to PID 1. Linux system administration, 2nd slide set © Jani Jaakkola 2019 15 SysVinit ● Ancient: Introduced by AT&T at UNIX system III at 1981. ● The system had 6 different runlevels. ○ However only few were actually used by Linux systems. ○ 1: single user mode (rescue mode) ○ 3: multi user mode ○ 5: graphical GUI mode with X server ○ 6: reboot ● The services that start and stop during startup are determined by the runlevel. ○ Every runlevel has a directory /etc/rcX.d which contains scripts that start services and daemons ○ Services are started sequentially in lexicographical order. ○ This is slow and prone to hangs when a service does not start. ● SysVinit is not used anymore in 2019. Old scripts might still exist though. Linux system administration, 2nd slide set © Jani Jaakkola 2019 16 Upstart and Devuan project ● Ubuntu wanted to replace SysVinit with something more modern: upstart ● Upstart was still in use in Ubuntu 14.04 installations, but was later replaced by systemd. ● Devuan project was established to provide a Linux distribution with old SysVinit and no systemd. Linux system administration, 2nd slide set © Jani Jaakkola 2019 17 Systemd Linux system administration, 2nd slide set © Jani Jaakkola 2019 18 Systemd ● Systemd has replaced init and most other system daemons in Linux distributions ○ Which is a the exact opposite of the old Unix philosophy: Do one thing and do it well.
Recommended publications
  • The Kernel Report

    The Kernel Report

    The kernel report (ELC 2012 edition) Jonathan Corbet LWN.net [email protected] The Plan Look at a year's worth of kernel work ...with an eye toward the future Starting off 2011 2.6.37 released - January 4, 2011 11,446 changes, 1,276 developers VFS scalability work (inode_lock removal) Block I/O bandwidth controller PPTP support Basic pNFS support Wakeup sources What have we done since then? Since 2.6.37: Five kernel releases have been made 59,000 changes have been merged 3069 developers have contributed to the kernel 416 companies have supported kernel development February As you can see in these posts, Ralink is sending patches for the upstream rt2x00 driver for their new chipsets, and not just dumping a huge, stand-alone tarball driver on the community, as they have done in the past. This shows a huge willingness to learn how to deal with the kernel community, and they should be strongly encouraged and praised for this major change in attitude. – Greg Kroah-Hartman, February 9 Employer contributions 2.6.38-3.2 Volunteers 13.9% Wolfson Micro 1.7% Red Hat 10.9% Samsung 1.6% Intel 7.3% Google 1.6% unknown 6.9% Oracle 1.5% Novell 4.0% Microsoft 1.4% IBM 3.6% AMD 1.3% TI 3.4% Freescale 1.3% Broadcom 3.1% Fujitsu 1.1% consultants 2.2% Atheros 1.1% Nokia 1.8% Wind River 1.0% Also in February Red Hat stops releasing individual kernel patches March 2.6.38 released – March 14, 2011 (9,577 changes from 1198 developers) Per-session group scheduling dcache scalability patch set Transmit packet steering Transparent huge pages Hierarchical block I/O bandwidth controller Somebody needs to get a grip in the ARM community.
  • Red Hat Enterprise Linux 7 7.1 Release Notes

    Red Hat Enterprise Linux 7 7.1 Release Notes

    Red Hat Enterprise Linux 7 7.1 Release Notes Release Notes for Red Hat Enterprise Linux 7 Red Hat Customer Content Services Red Hat Enterprise Linux 7 7.1 Release Notes Release Notes for Red Hat Enterprise Linux 7 Red Hat Customer Content Services Legal Notice Copyright © 2015 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
  • MLNX OFED Documentation Rev 5.0-2.1.8.0

    MLNX OFED Documentation Rev 5.0-2.1.8.0

    MLNX_OFED Documentation Rev 5.0-2.1.8.0 Exported on May/21/2020 06:13 AM https://docs.mellanox.com/x/JLV-AQ Notice This document is provided for information purposes only and shall not be regarded as a warranty of a certain functionality, condition, or quality of a product. NVIDIA Corporation (“NVIDIA”) makes no representations or warranties, expressed or implied, as to the accuracy or completeness of the information contained in this document and assumes no responsibility for any errors contained herein. NVIDIA shall have no liability for the consequences or use of such information or for any infringement of patents or other rights of third parties that may result from its use. This document is not a commitment to develop, release, or deliver any Material (defined below), code, or functionality. NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without notice. Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete. NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgement, unless otherwise agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual obligations are formed either directly or indirectly by this document. NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental damage.
  • Operating System Boot from Fully Encrypted Device

    Operating System Boot from Fully Encrypted Device

    Masaryk University Faculty of Informatics Operating system boot from fully encrypted device Bachelor’s Thesis Daniel Chromik Brno, Fall 2016 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Daniel Chromik Advisor: ing. Milan Brož i Acknowledgement I would like to thank my advisor, Ing. Milan Brož, for his guidance and his patience of a saint. Another round of thanks I would like to send towards my family and friends for their support. ii Abstract The goal of this work is description of existing solutions for boot- ing Linux and Windows from fully encrypted devices with Secure Boot. Before that, though, early boot process and bootloaders are de- scribed. A simple Linux distribution is then set up to boot from a fully encrypted device. And lastly, existing Windows encryption solutions are described. iii Keywords boot process, Linux, Windows, disk encryption, GRUB 2, LUKS iv Contents 1 Introduction ............................1 1.1 Thesis goals ..........................1 1.2 Thesis structure ........................2 2 Boot Process Description ....................3 2.1 Early Boot Process ......................3 2.2 Firmware interfaces ......................4 2.2.1 BIOS – Basic Input/Output System . .4 2.2.2 UEFI – Unified Extended Firmware Interface .5 2.3 Partitioning tables ......................5 2.3.1 MBR – Master Boot Record .
  • Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4

    Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4

    SUSE Linux Enterprise Server 12 SP4 Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4 Provides information about how to manage storage devices on a SUSE Linux Enterprise Server. 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 xii 2 Giving Feedback xiv 3 Documentation Conventions xiv 4 Product Life Cycle and Support xvi Support Statement for SUSE Linux Enterprise Server xvii • Technology Previews xviii I FILE SYSTEMS AND MOUNTING 1 1 Overview
  • Rootless Containers with Podman and Fuse-Overlayfs

    Rootless Containers with Podman and Fuse-Overlayfs

    CernVM Workshop 2019 (4th June 2019) Rootless containers with Podman and fuse-overlayfs Giuseppe Scrivano @gscrivano Introduction 2 Rootless Containers • “Rootless containers refers to the ability for an unprivileged user (i.e. non-root user) to create, run and otherwise manage containers.” (https://rootlesscontaine.rs/ ) • Not just about running the container payload as an unprivileged user • Container runtime runs also as an unprivileged user 3 Don’t confuse with... • sudo podman run --user foo – Executes the process in the container as non-root – Podman and the OCI runtime still running as root • USER instruction in Dockerfile – same as above – Notably you can’t RUN dnf install ... 4 Don’t confuse with... • podman run --uidmap – Execute containers as a non-root user, using user namespaces – Most similar to rootless containers, but still requires podman and runc to run as root 5 Motivation of Rootless Containers • To mitigate potential vulnerability of container runtimes • To allow users of shared machines (e.g. HPC) to run containers without the risk of breaking other users environments • To isolate nested containers 6 Caveat: Not a panacea • Although rootless containers could mitigate these vulnerabilities, it is not a panacea , especially it is powerless against kernel (and hardware) vulnerabilities – CVE 2013-1858, CVE-2015-1328, CVE-2018-18955 • Castle approach : it should be used in conjunction with other security layers such as seccomp and SELinux 7 Podman 8 Rootless Podman Podman is a daemon-less alternative to Docker • $ alias
  • White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins

    White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins

    White Paper: Indestructible Firewall In A Box v1.0 Nick McCubbins 1.1 Credits • Nathan Yawn ([email protected]) 1.2 Acknowledgements • Firewall-HOWTO • Linux Router Project • LEM 1.3 Revision History • Version 1.0 First public release 1.4 Feedback • Send all information and/or criticisms to [email protected] 1.5 Distribution Policy 2 Abstract In this document, the procedure for creating an embedded firewall whose root filesystem is loaded from a flash disk and then executed from a RAMdisk will be illustrated. A machine such as this has uses in many environments, from corporate internet access to sharing of a cable modem or xDSL connection among many computers. It has the advantages of being very light and fast, being impervious to filesystem corruption due to power loss, and being largely impervious to malicious crackers. The type of firewall illustrated herein is a simple packet-filtering, masquerading setup. Facilities for this already exist in the Linux kernel, keeping the system's memory footprint small. As such the device lends itself to embedding very well. For a more detailed description of firewall particulars, see the Linux Firewall-HOWTO. 3 Equipment This project has minimal hardware requirements. An excellent configuration consists of: For a 100-baseT network: • SBC-554 Pentium SBC with PISA bus and on-board PCI NIC (http://www.emacinc.com/pc.htm#pentiumsbc), approx. $373 • PISA backplane, chassis, power supply (http://www.emacinc.com/sbcpc_addons/mbpc641.htm), approx. $305 • Second PCI NIC • 32 MB RAM • 4 MB M-Systems Flash Disk (minimum), approx. $45 For a 10-baseT network: • EMAC's Standard Server-in-a-Box product (http://www.emacinc.com/server_in_a_box.htm), approx.
  • ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction.
  • Open Source Licensing Information for Cisco IP Phone 8800 Series

    Open Source Licensing Information for Cisco IP Phone 8800 Series

    Open Source Used In Cisco IP Phone 8800 Series 12.1(1) Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-163803748 Open Source Used In Cisco IP Phone 8800 Series 12.1(1) 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-163803748 Contents 1.1 bluez 4.101 :MxC-1.1C R4.0 1.1.1 Available under license 1.2 BOOST C++ Library 1.63.0 1.2.1 Available under license 1.3 busybox 1.21.0 1.3.1 Available under license 1.4 Busybox 1.23.1 1.4.1 Available under license 1.5 cjose 0.4.1 1.5.1 Available under license 1.6 cppformat 2.0.0 1.6.1 Available under license 1.7 curl 7.26.0 1.7.1 Available under license 1.8 dbus 1.4.1 :MxC-1.1C R4.0 1.8.1 Available under license 1.9 DirectFB library and utilities 1.4.5 1.9.1 Available under license 1.10 dnsmasq 2.46 1.10.1 Available under license 1.11 flite 2.0.0 1.11.1 Available under license 1.12 glibc 2.13 1.12.1 Available under license 1.13 hostapd 2.0 :MxC-1.1C R4.0 1.13.1 Available under license Open Source Used
  • NVIDIA Magnum IO Gpudirect Storage

    NVIDIA Magnum IO Gpudirect Storage

    NVIDIA Magnum IO GPUDirect Storage Installation and Troubleshooting Guide TB-10112-001_v1.0.0 | August 2021 Table of Contents Chapter 1. Introduction........................................................................................................ 1 Chapter 2. Installing GPUDirect Storage.............................................................................2 2.1. Before You Install GDS.............................................................................................................2 2.2. Installing GDS............................................................................................................................3 2.2.1. Removal of Prior GDS Installation on Ubuntu Systems...................................................3 2.2.2. Preparing the OS................................................................................................................3 2.2.3. GDS Package Installation.................................................................................................. 4 2.2.4. Verifying the Package Installation.....................................................................................4 2.2.5. Verifying a Successful GDS Installation............................................................................5 2.3. Installed GDS Libraries and Tools...........................................................................................6 2.4. Uninstalling GPUDirect Storage...............................................................................................7 2.5. Environment
  • De-Anonymizing Live Cds Through Physical Memory Analysis

    De-Anonymizing Live Cds Through Physical Memory Analysis

    De-Anonymizing Live CDs through Physical Memory Analysis Andrew Case [email protected] Digital Forensics Solutions Abstract Traditional digital forensics encompasses the examination of data from an offline or “dead” source such as a disk image. Since the filesystem is intact on these images, a number of forensics techniques are available for analysis such as file and metadata examination, timelining, deleted file recovery, indexing, and searching. Live CDs present a serious problem for this investigative model, however, since the OS and applications execute in a RAM-only environment and do not save data on non-volatile storage devices such as the local disk. In order to solve this problem, we present a number of techniques that support complete recovery of a live CD’s in-memory filesystem and partial recovery of its deleted contents. We also present memory analysis of the popular Tor application, since it is used by a number of live CDs in an attempt to keep network communications encrypted and anonymous. 1 Introduction Traditional digital forensics encompasses the examination of data from an offline or “dead” source such as a disk image. Under normal circumstances, evidence is obtained by first creating an exact, bit-for-bit copy of the target disk, followed by hashing of both the target disk and the new copy. If these hashes match then it is known that an exact copy has been made, and the hash is recorded to later prove that evidence was not modified during the investigation. Besides satisfying legal requirements, obtaining a bit-for-bit copy of data provides investigators with a wealth of information to examine and makes available a number of forensics techniques.
  • Ivoyeur: Inotify

    Ivoyeur: Inotify

    COLUMNS iVoyeur inotify DAVE JOSEPHSEN Dave Josephsen is the he last time I changed jobs, the magnitude of the change didn’t really author of Building a sink in until the morning of my first day, when I took a different com- Monitoring Infrastructure bination of freeways to work. The difference was accentuated by the with Nagios (Prentice Hall T PTR, 2007) and is Senior fact that the new commute began the same as the old one, but on this morn- Systems Engineer at DBG, Inc., where he ing, at a particular interchange, I would zig where before I zagged. maintains a gaggle of geographically dispersed It was an unexpectedly emotional and profound metaphor for the change. My old place was server farms. He won LISA ‘04’s Best Paper off to the side, and down below, while my future was straight ahead, and literally under award for his co-authored work on spam construction. mitigation, and he donates his spare time to the SourceMage GNU Linux Project. The fact that it was under construction was poetic but not surprising. Most of the roads I [email protected] travel in the Dallas/Fort Worth area are under construction and have been for as long as anyone can remember. And I don’t mean a lane closed here or there. Our roads drift and wan- der like leaves in the water—here today and tomorrow over there. The exits and entrances, neither a part of this road or that, seem unable to anticipate the movements of their brethren, and are constantly forced to react.