DOCSLIB.ORG

Copyrighted Material

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Index SYMBOLS tool, 63 %n format specifi er, 403 ADBI framework, 492 Add Native Support menu item, A 226–227 abootimg tool, 330 addresses Abstract Namespace Socket, 165 address lines, unexposed, 482 access control mechanisms address space layout (kernels), 350 (mitigations), 407–408 extracting (Linux kernel), 350–352 Access Point Name (APN), 137 adjacency (networking), 137–139 Activities (Android applications), Adleman, Leonard, 413 36–37 ADT Bundle, 213 Activities (IPC endpoint), 89–90 ADT plug-in (Eclipse), 226, 486 ActivityManager, 193–194 Adventures in Bouncerland, 152 ad networks (attack surfaces), 146–147 adware, 147 ADB (Android Debugging Bridge) Aedla, Jüri, 78 access via TCP/IP, 140 agent-proxy program, 346 ADB binaries, 227–228 ahh_setuid module, 324 ADB daemon, physical attacks via, AIDL (Android Interface Defi nition 173 COPYRIGHTED MATERIALLanguage), 51–52 adb restore command race alephzain, 80 condition, 80 allocated blocks, controlling heap adb root command, 218 with (Android browser), 289–290 adbd daemon, 69 AllWinner SoC ARM core, basics, 46–47 503 monitoring Android phones with, am command, 231 386 AndBug debugger, 112–113 523 524 Index ■ A–A Androguard framework, 95–96, controlling heap with free blocks, 493–494 288–289 Android CVE-2011-3068 bug, 284–287 Android on Intel Architecture Android Developer Tools (ADT) (Android-IA) project, 10 bundle, 486–487 Android Secure Container (ASEC) plug-in, 212 fi les, 47 Android ecosystem Android Studio, 487 company history, 2 Android-centric fork (Linux kernel), compatibility requirements, 17–18 49–50 complexities of, 15–16 AndroidManifest.xml fi le, 30, 35 device pool, 4–6 Android.Troj.mdk Trojan, 151 fragmentation of, 16 application packages (APKs), 35 open source components, 7 application Support Library, 17 public disclosures, 22–23 applications, 34–39 security vs. openness, 21–22 building from source, 67 stakeholders. See stakeholders, Compatibility Defi nitions, 63 Android Device Monitor, 212 update issues, 18–21 dlmalloc allocator (heap version history, 2–4 exploitation), 269–271 Android Framework emulator, 86 basics, 39–40 exposed UART on, 426–428 licensing, 12 GDB binary, 245 overview of, 26 heap debugging, 248–249 Android telephony stack IDs (AIDs), 27–28 basics, 370–371 Interface Defi nition Language customization of, 371–372 (AIDL), 51–52 AndroProbe, 246 logging system architecture, 53 Anonymous Shared Memory Native Development Kit (NDK), 486 (ashmem) (Linux kernel), 52, 167 Software Development Kit (SDK), anti-reversing epoxies, 482 93–94, 485–486 aobj ARSCParser object, 106 system architecture, 25–27 AOSP (Android Open Source Project) Update Alliance, 21 custom kernels for AOSP-supported Android 4.0.1 linker case study (ROP) devices, 325–326 executing arbitrary code from new getting kernel source, 317–319 mapping, 303–307 Git repositories, 501–502 overview of, 300–301 indexes of AOSP source code, 510 pivoting stack pointer, 301–303 initializing, 215 Android browser exploitation native code debugging with, 227–233 controlling heap with allocated native code debugging with non- blocks, 289–290 AOSP devices, 241–243 controlling heap with CSS, 287–288 Nexus devices supported by, 5 Index ■ A–A 525 prebuilts directory, 229 ARM ABI (Application Binary Apache Ant, 223 Interface), 295 Apache HTTP client libraries, 39 ARM Linux debugger, 207–208 Apache Software License, 7 ARM9TDMI implementation, 292 API permissions, 32 licensing and designs, 10 apktool (Java tool), 94, 494 ROP on. See ROP on ARM app markets, 13 separate instructions and data app permissions, 27, 84–86 caches, 292–294 Application Framework components SOC families in ARM devices, 11 (RIL), 371 subroutine calls (ROP on ARM), application layer (OSI model), 136 295–297 application processor (smartphones), arm-eabi compiler, 322 369 ARP spoofi ng, 138 application security ashmem (Anonymous Shared app permission issues, 84–86 Memory) (Linux kernel), 52 information leakage through logs, ASLR (Address Space Layout 88–89 Randomization) insecure data storage, 87–88 basics, 398–400 insecure transmission of sensitive overcoming, 418–419 data, 86 asroot exploit, 74 mobile security (app case study). See Asus mobile security app (case study) ASUS Transformer Prime, overview of, 83–84 79 SIP client (case study). See SIP client open source repositories, 506 (case study) stock fi rmware (kernels), 312 unsecured IPC endpoints, 89–91 attack phase (mobile security app), application testing tools, 496 117–120 app-locked device screen, 120 attack surfaces (Android) app.provider.query module, 125 basics, 131–132 apps classifying, 134 debugging with NDK, 222–226 local attack surfaces. See local attack malicious, 149 surfaces Verify Apps feature (Google), 150– physical. See physical attack surfaces 151 physical adjacency, 154–161 web-powered mobile (attacks), remote. See remote attack surfaces 145–146 surface properties, 133 argv array, 281–282 third-party modifi cations, Arithmetic Logic Unit (ALU) status 174 fl ags, 341 attacks ARM architecture attack vectors, 130–131 ABI rules used on, 264 overview of, 129–130 526 Index ■ B–B root access. See root access attack Block View tool, 461 history blown debug interfaces, 480 automating Bluetooth (attack surfaces), 157–158 GDB client, 235 BluetoothOppService, 38 on-device tasks, 233–234 Board Support Packages (BSPs), 502–503 B boot command, 332 Babel fi sh, JTAG, 437 boot images back-porting, 20 creating, 329–331 backtrace GDB command, 252 extracting kernels from, 315 Baker, Mike, 74 boot loaders Baksmali disassembler, 493 boot partition (NAND fl ash Barra, Hugo, 20 memory), 58 Baseband Attacks: Remote Exploitation locked/unlocked, 62–65 of Memory Corruptions inCellular passwords/hot keys/silent terminals, Protocol Stacks, 480 480–481 baseband communication, rild rooting with locked/unlocked, 65–69 interaction with, 375 U-Boot, 468–469 baseband interface (smartphones), 167 unlock tools, 70 baseband processors (attack surfaces), boot partitions 156–157 fl ashing, 333 basebands (smartphones), 369 getting images of, 310–311 Bassel, Larry, 410 NAND fl ash memory, 58 BCM3349 series chip, 447 recovery partition and, 314, 329–330 Beagle device (Total Phase), 464 writing directly to, 334–335 Beagle I2C (Total Phase), 498 boot process, 60–62 Beagle USB (Total Phase), 498 booted systems, gaining root access beaming data, 159 on, 69 Bergman, Neil, 88 boot.img fi le, 315 bin arrays, 270 booting binaries, altering (exploit mitigations), custom kernels, 331–336 416–417 customized boot sequences, 481–482 Binder driver (Linux kernel) Borgaonkar, Ravi, 142 attack surfaces, 166–167 Bouncer system (attack surfaces), basics, 50–52 151–152 IPC and, 310 break command (AndBug), 116 Binwalk, 487 breakpoints binwalk tool, 316, 475 interdependent, 250 Bionic C runtime library (Android), setting in “Hello World” module, 248 347–348 Bionic library, 42 Broadcast Receivers Index ■ C–C 527 basics, 37 fuzzing. See fuzzing Chrome for fuzz testing. See fuzzing Broadcast Android Receivers Google Play updates for, 144–145 handling implicit Intent messages client-side attack surfaces, 143–148 with, 89 coalescing with blocks, 270–271 onReceive method and, 101 code browser attack surfaces, 143–145 behind sockets, fi nding, 165–166 browser exploitation, Android. See Code Aurora forum (Qualcomm), 23 Android browser exploitation Code Division Multiple Access BrowserFuzz, 188, 193–194, 197 (CDMA), 154 Bus Pirate device, 465–468, 497 code signing, 392–394, 422 bus resets (USB devices), 198 Common Attack Pattern Enumeration busybox binary, 165–166, 491 and Classifi cation (CAPEC), 130 BusyBox tool, 231 Common Vulnerabilities and Butler, Jon, 190 Exposures (CVE) project, 23, 352– 353 C Common Vulnerability Scoring The C ++ Programming Language System (CVSS), 130 (Addison Wesley), 272 company history (Android), 2 C++ virtual function table pointers, Compatibility Defi nition Document 271–273 (CDD), 327 caches compatibility requirements (Android), cache partition (NAND fl ash 17–18 memory), 59 Compatibility Test Suite (CTS), 349 instructions and data (ARM), 292– Complex Instruction Set Computing 294 (CISC), 299 calloc function, 395 components, identifying hardware, canhazaxs tool, 162–163 456–458 carriers (stakeholders), 12 CONFIG_KALLSYMS confi guration Case, Justin, 87 option, 350 cat binary on Android, 400 CONFIG_SEC_ RESTRICT_FORKK kernel CDD (Compatibility Defi nition option, 412 Document), 18 CONFIG_SEC_RESTRICT_SETUID cellular modem (smartphones), kernel option, 412 369 CONFIG_STRICT_MEMORY_RWX kernel certifi cate pinning, 146 confi guration, 410–411 Chainfi re SuperSU, 66 confi gurations chip passwords, 480 confi guring kernel, 321–322, 349 Chip Quik, 472, 498 confi guring parameters for enabling chips, removing, 471–474 KGDB, 344 Chrome for Android browser and defenses (networking), 136–137 528 Index ■ D–D Package on Package (PoP), 458 building, 325–329 Conover, Matthew, 394 confi guring kernel, 321–322 consumers, features desired by, 14 creating boot images, 329–331 ContainerNode HTML element, 257 obtaining source code, 316–320 Content Providers setting up build environment, basics, 38–39 320–321 discovery of URIs (SIP client), 121– using custom kernel modules, 122 322–325 exported attribute of, 413 custom recovery images, 63–65 vulnerability of, 89 custom ROMs, 13–14 Cook, Kees, 409, 421 customized boot sequences, 481 core services CVE-2011-3068 bug (Android browser), Android Debugging Bridge (ADB), 284–287 46–47 CyanogenMod, 13 debuggerd, 46 Cydia Substrate for Android, 493 init command, 42–44 other services,
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.
  • Oracle® Linux Administrator's Solutions Guide for Release 6

    Oracle® Linux Administrator's Solutions Guide for Release 6

    Oracle® Linux Administrator's Solutions Guide for Release 6 E37355-64 August 2017 Oracle Legal Notices Copyright © 2012, 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
  • 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
  • Kdump, a Kexec-Based Kernel Crash Dumping Mechanism

    Kdump, a Kexec-Based Kernel Crash Dumping Mechanism

    Kdump, A Kexec-based Kernel Crash Dumping Mechanism Vivek Goyal Eric W. Biederman Hariprasad Nellitheertha IBM Linux NetworkX IBM [email protected] [email protected] [email protected] Abstract important consideration for the success of a so- lution has been the reliability and ease of use. Kdump is a crash dumping solution that pro- Kdump is a kexec based kernel crash dump- vides a very reliable dump generation and cap- ing mechanism, which is being perceived as turing mechanism [01]. It is simple, easy to a reliable crash dumping solution for Linux R . configure and provides a great deal of flexibility This paper begins with brief description of what in terms of dump device selection, dump saving kexec is and what it can do in general case, and mechanism, and plugging-in filtering mecha- then details how kexec has been modified to nism. boot a new kernel even in a system crash event. The idea of kdump has been around for Kexec enables booting into a new kernel while quite some time now, and initial patches for preserving the memory contents in a crash sce- kdump implementation were posted to the nario, and kdump uses this feature to capture Linux kernel mailing list last year [03]. Since the kernel crash dump. Physical memory lay- then, kdump has undergone significant design out and processor state are encoded in ELF core changes to ensure improved reliability, en- format, and these headers are stored in a re- hanced ease of use and cleaner interfaces. This served section of memory. Upon a crash, new paper starts with an overview of the kdump de- kernel boots up from reserved memory and pro- sign and development history.
  • Coreboot - the Free Firmware

    Coreboot - the Free Firmware

    coreboot - the free firmware vimacs <https://vimacs.lcpu.club> Linux Club of Peking University May 19th, 2018 . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 1 / 77 License This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. You can find the source code of this presentation at: https://git.wehack.space/coreboot-talk/ . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 2 / 77 Index 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 3 / 77 Index 6 Porting coreboot with autoport ASRock B75 Pro3-M Sandy/Ivy Bridge HP Elitebooks Dell Latitude E6230 7 References . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 4 / 77 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 5 / 77 What is coreboot? coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology. The word ’coreboot’ should always be written in lowercase, even at the start of a sentence. vimacs (LCPU) coreboot - the free firmware May 19th, 2018 6 / 77 History: from LinuxBIOS to coreboot coreboot has a very long history, stretching back more than 18 years to when it was known as LinuxBIOS.
  • Arxiv:1907.06110V1 [Cs.DC] 13 Jul 2019 (TCB) with Millions of Lines of Code and a Massive Attack Enclave” of Physical Machines

    Arxiv:1907.06110V1 [Cs.DC] 13 Jul 2019 (TCB) with Millions of Lines of Code and a Massive Attack Enclave” of Physical Machines

    Supporting Security Sensitive Tenants in a Bare-Metal Cloud∗† Amin Mosayyebzadeh1, Apoorve Mohan4, Sahil Tikale1, Mania Abdi4, Nabil Schear2, Charles Munson2, Trammell Hudson3 Larry Rudolph3, Gene Cooperman4, Peter Desnoyers4, Orran Krieger1 1Boston University 2MIT Lincoln Laboratory 3Two Sigma 4Northeastern University Abstract operations and implementations; the tenant needs to fully trust the non-maliciousness and competence of the provider. Bolted is a new architecture for bare-metal clouds that en- ables tenants to control tradeoffs between security, price, and While bare-metal clouds [27,46,48,64,66] eliminate the performance. Security-sensitive tenants can minimize their security concerns implicit in virtualization, they do not ad- trust in the public cloud provider and achieve similar levels of dress the rest of the challenges described above. For example, security and control that they can obtain in their own private OpenStack’s bare-metal service still has all of OpenStack in data centers. At the same time, Bolted neither imposes over- the TCB. As another example, existing bare-metal clouds en- head on tenants that are security insensitive nor compromises sure that previous tenants have not compromised firmware by the flexibility or operational efficiency of the provider. Our adopting a one-size-fits-all approach of validation/attestation prototype exploits a novel provisioning system and special- or re-flashing firmware. The tenant has no way to program- ized firmware to enable elasticity similar to virtualized clouds. matically verify the firmware installed and needs to fully trust Experimentally we quantify the cost of different levels of se- the provider. As yet another example, existing bare-metal curity for a variety of workloads and demonstrate the value clouds require the tenant to trust the provider to scrub any of giving control to the tenant.
  • Practical and Effective Sandboxing for Non-Root Users

    Practical and Effective Sandboxing for Non-Root Users

    Practical and effective sandboxing for non-root users Taesoo Kim and Nickolai Zeldovich MIT CSAIL Abstract special tools. More importantly, all use cases neither re- quire root privilege nor require modification to the OS MBOX is a lightweight sandboxing mechanism for non- kernel and applications. root users in commodity OSes. MBOX’s sandbox usage model executes a program in the sandbox and prevents Overview MBOX aims to make running a program in a the program from modifying the host filesystem by layer- sandbox as easy as running the program itself. For exam- ing the sandbox filesystem on top of the host filesystem. ple, one can sandbox a program (say wget) by running as At the end of program execution, the user can examine below: changes in the sandbox filesystem and selectively com- mit them back to the host filesystem. MBOX implements $ mbox -- wget google.com ... this by interposing on system calls and provides a variety Network Summary: of useful applications: installing system packages as a > [11279] -> 173.194.43.51:80 > [11279] Create socket(PF_INET,...) non-root user, running unknown binaries safely without > [11279] -> a00::2607:f8b0:4006:803:0 network accesses, checkpointing the host filesystem in- ... Sandbox Root: stantly, and setting up a virtual development environment > /tmp/sandbox-11275 without special tools. Our performance evaluation shows > N:/tmp/index.html [c]ommit, [i]gnore, [d]iff, [l]ist, [s]hell, [q]uit ?> that MBOX imposes CPU overheads of 0.1–45.2% for var- ious workloads. In this paper, we present MBOX’s design, wget is a utility to download files from the web.
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M

    Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M

    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
  • Hardening Kubernetes Containers Security with Seccomp an Often Overlooked Way to Harden Kubernetes Containers’ Security Is by Applying Seccomp Profiles

    Hardening Kubernetes Containers Security with Seccomp an Often Overlooked Way to Harden Kubernetes Containers’ Security Is by Applying Seccomp Profiles

    eBook: Hardening Kubernetes Containers Security with Seccomp An often overlooked way to harden Kubernetes containers’ security is by applying seccomp profiles. A relatively ancient security mechanism in the Linux kernel, seccomp (short for secure computing mode) tells the Linux kernel which system calls a process can make. Restricting a process from accessing the kernel via system calls restricts the attack surface, and can prevent privilege escalation. The original seccomp was very restrictive and unwieldy to use. The first version of seccomp was merged in 2005 into Linux 2.6.12. It was enabled by writing a "1" to /proc/PID/seccomp. Then, the process could only make 4 syscalls: read(), write(), exit(), and sigreturn()"). Today, the seccomp-bpf extension, which uses the Berkeley Packet Filter rules, is more commonly used as it allows filtering system calls using a configurable policy. 1 Given the number of system calls invoked to execute a Customizing seccomp profiles, in effect, provides a container, each of which is a potential entry vector for deeply embedded line of defense that adds a layer of attackers, appropriately applying seccomp profiles goes a protection to your application in case of breach. As the long way to securing a container. probability of any application being breached is constantly rising, limiting the possible extent of a successful breach should be applied at as many levels as possible. Ever-increasing interconnections between applications, and increased reliance on external service providers as well as open-source images makes restricting seccomp profiles crucial to improving cloud-native security. Filtering system calls is not the same as sandboxing.
  • Enclave Security and Address-Based Side Channels

    Enclave Security and Address-Based Side Channels

    Graz University of Technology Faculty of Computer Science Institute of Applied Information Processing and Communications IAIK Enclave Security and Address-based Side Channels Assessors: A PhD Thesis Presented to the Prof. Stefan Mangard Faculty of Computer Science in Prof. Thomas Eisenbarth Fulfillment of the Requirements for the PhD Degree by June 2020 Samuel Weiser Samuel Weiser Enclave Security and Address-based Side Channels DOCTORAL THESIS to achieve the university degree of Doctor of Technical Sciences; Dr. techn. submitted to Graz University of Technology Assessors Prof. Stefan Mangard Institute of Applied Information Processing and Communications Graz University of Technology Prof. Thomas Eisenbarth Institute for IT Security Universit¨atzu L¨ubeck Graz, June 2020 SSS AFFIDAVIT I declare that I have authored this thesis independently, that I have not used other than the declared sources/resources, and that I have explicitly indicated all material which has been quoted either literally or by content from the sources used. The text document uploaded to TUGRAZonline is identical to the present doctoral thesis. Date, Signature SSS Prologue Everyone has the right to life, liberty and security of person. Universal Declaration of Human Rights, Article 3 Our life turned digital, and so did we. Not long ago, the globalized commu- nication that we enjoy today on an everyday basis was the privilege of a few. Nowadays, artificial intelligence in the cloud, smartified handhelds, low-power Internet-of-Things gadgets, and self-maneuvering objects in the physical world are promising us unthinkable freedom in shaping our personal lives as well as society as a whole. Sadly, our collective excitement about the \new", the \better", the \more", the \instant", has overruled our sense of security and privacy.
  • SUSE Linux Enterprise Server 15 SP2 Autoyast Guide Autoyast Guide SUSE Linux Enterprise Server 15 SP2

    SUSE Linux Enterprise Server 15 SP2 Autoyast Guide Autoyast Guide SUSE Linux Enterprise Server 15 SP2

    SUSE Linux Enterprise Server 15 SP2 AutoYaST Guide AutoYaST Guide SUSE Linux Enterprise Server 15 SP2 AutoYaST is a system for unattended mass deployment of SUSE Linux Enterprise Server systems. AutoYaST installations are performed using an AutoYaST control le (also called a “prole”) with your customized installation and conguration data. 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 1 Introduction to AutoYaST 1 1.1 Motivation 1 1.2 Overview and Concept 1 I UNDERSTANDING AND CREATING THE AUTOYAST CONTROL FILE 4 2 The AutoYaST Control
  • Beyond Init: Systemd Linux Plumbers Conference 2010

    Beyond Init: Systemd Linux Plumbers Conference 2010

    Beyond Init: systemd Linux Plumbers Conference 2010 Kay Sievers Lennart Poettering November 2010 Kay Sievers, Lennart Poettering Beyond Init: systemd Triggers: Boot, Socket, Bus, Device, Path, Timers, More Kay Sievers, Lennart Poettering Beyond Init: systemd Kay Sievers, Lennart Poettering Beyond Init: systemd Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Kay Sievers, Lennart Poettering Beyond Init: systemd including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, Kay Sievers, Lennart Poettering Beyond Init: systemd mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, Kay Sievers, Lennart Poettering Beyond Init: systemd quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, mount, Kay Sievers, Lennart Poettering Beyond Init: systemd hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, Kay Sievers, Lennart Poettering Beyond Init: systemd readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots.