DOCSLIB.ORG

Security Namespace : Making Linux Security Frameworks Available to Containers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Security Namespace : Making Linux Security Frameworks Available to Containers Security Namespace : Making Linux Security Frameworks Available to Containers Yuqiong Sun David Safford Mimi Zohar Symantec Research Labs GE Global Research IBM Research Dimitrios Pendarakis Zhongshu Gu Trent Jaeger IBM Research IBM Research Pennsylvania State University Abstract 1 Introduction Lightweight virtualization (i.e., containers) offers a vir- tual host environment for applications without the need Lightweight virtualization (i.e., containers) offers a vir- for a separate kernel, enabling better resource utiliza- tual host environment for applications without the need tion and improved efficiency. It is broadly used in com- for a separate kernel, enabling better resource utiliza- putation scenarios where a dense deployment and fast tion and improved efficiency. However, the shared ker- spin-up speed is required, such as microservice archi- nel also prevents containers from taking advantage of se- tecture [39] and serverless computation (e.g., Amazon curity features that are available to traditional VMs and Lambda [26]). Many commercial cloud vendors [23, 20, hosts. Containers cannot apply local policies to gov- 1] have adopted the technology. ern integrity measurement, code execution, mandatory access control, etc. to prevent application-specific se- The key difference between containers and traditional curity problems. Changes have been proposed to make VMs is that containers share the same kernel. While this kernel security mechanisms available to containers, but enables better resource utilization, it also prevents con- such changes are often adhoc and expose the challenges tainers from taking advantage of security features in ker- of trusting containers to make security decisions without nel that are available to traditional VMs or hosts. Con- compromising host system or other containers. In this tainers cannot apply local security policies to govern in- paper, we propose security namespaces, a kernel abstrac- tegrity measurement, code execution, mandatory access tion that enables containers to have an autonomous con- control, etc. to prevent application specific security prob- trol over their security. The security namespace relaxes lems. Instead, they have to rely on a global policy spec- the global and mandatory assumption of kernel security ified by the host system admin, who often has different frameworks, thus enabling containers to independently security interests (i.e., protect the host system) and does define security policies and apply them to a limited scope not have enough insight about the security needs of indi- of processes. To preserve security, we propose a routing vidual containers. As a result, containers often run with- mechanism that can dynamically dispatch an operation out any protection [34, 40]. to a set of containers whose security might be affected Previous efforts of making kernel security frameworks by the operation, therefore ensuring the security decision available to containers are often adhoc and expose the made by one container cannot compromise the host or challenges of trusting containers to make security deci- other containers. We demonstrate security namespace by sions without compromising host system or other con- developing namespaces for integrity measurement and tainers. For example, a kernel patch [24] to Integrity mandatory access control in the Linux kernel for use by Measurement Architecture (IMA) [53] suggested that the Docker containers. Results show that security names- IMA measurement list can be extended with a container paces can effectively mitigate security problems within ID, such that during integrity attestation the measure- containers (e.g., malicious code execution) with less than ments will become separable based on containers. As 0.7% additional latency to system call and almost identi- another example, AppArmor and Tomoyo introduced the cal application throughput. As a result, security names- concept of profile and policy namespace [49, 44] to allow paces enable containers to obtain autonomous control certain processes to run under a policy different from the over their security without compromising the security of rest of the system. These changes, however, only made other containers or the host system. limited kernel security features available to containers, and they all rely on the system owner to specify a global form the container owners of potential conflicts before policy, leaving containers no real freedom in enforcing they load their security policies. an autonomous security. We evaluate our design by developing two concrete in- In this paper, we explore approaches to make kernel stances of security namespace, one for IMA and one for security frameworks available to containers. Due to the AppArmor. Results show that leveraging the namespace diversity of kernel security frameworks and their differ- abstractions, containers (e.g., Docker and LXC) can ex- ent design perspectives and details, it is extremely dif- ercise the full functionality of IMA and AppArmor and ficult to reach a generic design that can cover all ker- apply autonomous security control, much like a VM or nel security frameworks in a single step. Instead, this host system. Specifically, we show that the IMA names- paper explores an initial step, by making two concrete pace enables containers to independently measure and kernel security frameworks available to containers, to in- appraise files that are loaded into the container, with- vestigate the common challenges and approaches behind. out violating any of the host system’s integrity policy. Hopefully, the results have enough generality to guide For AppArmor namespace, we show that it enables con- other kernel security frameworks and eventually lead to a tainers to enforce two policy profiles simultaneously, one generic design. In studying the two popular kernel secu- protects the host system and another protects the con- rity frameworks, namely IMA [53] for integrity and Ap- tainerized application, which was not possible as dis- pArmor [41] for mandatory access control, we make the cussed in Ubuntu LXC documentation [34]. We evaluate following observations: first, we find that the common the performance of both namespace abstractions. Results challenge for containers to obtain autonomous security show that security namespaces introduce less than 0.7% control is the implicit global and mandatory assumptions latency overhead to system calls in a typical container that kernel security frameworks often make. Kernel se- cloud use case (i.e., no nested namespaces) and an al- curity frameworks are designed to be global—they con- most identical throughput for containerized applications. trol all processes running on the system. They are also In summary, we make the following contributions. designed to be mandatory—only the owner of the system • Through studying IMA and AppArmor, we inves- may apply a security policy. However, autonomous se- tigate the common challenges and approaches be- curity control requires relaxation of both assumptions. A hind making kernel security frameworks available container need to apply local security policies to control to containers. a subset of processes running on the system (i.e., pro- cesses in the container). Relaxing these assumptions in- • We develop two concrete security namespace ab- volves security risks. Our second insight is that we can stractions, one for IMA and another for AppArmor, relax the global and mandatory assumptions in a secure which enables autonomous security control for con- way by checking if the autonomous security control of tainers while preserving security. a container may compromise the security of other con- tainers or the host system. We do this by inferring from • We show that widely used container systems (e.g., containers’ security expectation towards an operation. Docker and LXC) can easily adopt the IMA and AppArmor security namespace abstractions to exer- Leveraging these insights, we propose the design of cise full functionality of kernel security frameworks security namespaces, kernel abstractions that enable con- with modest overhead. tainers to utilize kernel security frameworks to apply au- tonomous security control. Security namespace virtual- 2 Background izes kernel security frameworks into virtual instances, In this section, we first describe the namespace concept one per container. Each virtual instance applies inde- in the Linux kernel and how it is adopted by container. pendent security policies to control containerized pro- We then discuss security frameworks in Linux kernel. cesses and maintains their independent security states. To ensure that the relaxation does not compromise any 2.1 Namespace and Container principal’s security (i.e., other containers or the host sys- The Linux namespace abstraction provides isolation for tem), an Operation Router is inserted before the virtual various system resources. According to Linux man instances mediating an operation. The Operation Router page [31]: decides the set of virtual instances whose security might be affected by an operation and routes the operation to A namespace wraps a global system resource those virtual instance for mediation. After each virtual in an abstraction that makes it appear to the instance makes an independent security decision, the de- processes within the namespace that they have cisions are intersected. A specific challenge is that vir- their own isolated instance of the global re- tual instances may make conflicting security decisions. source. Changes to the global resource are A Policy
Load more

Recommended publications
  • 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.
    [Show full text]
  • 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
    [Show full text]
  • In Search of the Ideal Storage Configuration for Docker Containers
    In Search of the Ideal Storage Configuration for Docker Containers Vasily Tarasov1, Lukas Rupprecht1, Dimitris Skourtis1, Amit Warke1, Dean Hildebrand1 Mohamed Mohamed1, Nagapramod Mandagere1, Wenji Li2, Raju Rangaswami3, Ming Zhao2 1IBM Research—Almaden 2Arizona State University 3Florida International University Abstract—Containers are a widely successful technology today every running container. This would cause a great burden on popularized by Docker. Containers improve system utilization by the I/O subsystem and make container start time unacceptably increasing workload density. Docker containers enable seamless high for many workloads. As a result, copy-on-write (CoW) deployment of workloads across development, test, and produc- tion environments. Docker’s unique approach to data manage- storage and storage snapshots are popularly used and images ment, which involves frequent snapshot creation and removal, are structured in layers. A layer consists of a set of files and presents a new set of exciting challenges for storage systems. At layers with the same content can be shared across images, the same time, storage management for Docker containers has reducing the amount of storage required to run containers. remained largely unexplored with a dizzying array of solution With Docker, one can choose Aufs [6], Overlay2 [7], choices and configuration options. In this paper we unravel the multi-faceted nature of Docker storage and demonstrate its Btrfs [8], or device-mapper (dm) [9] as storage drivers which impact on system and workload performance. As we uncover provide the required snapshotting and CoW capabilities for new properties of the popular Docker storage drivers, this is a images. None of these solutions, however, were designed with sobering reminder that widespread use of new technologies can Docker in mind and their effectiveness for Docker has not been often precede their careful evaluation.
    [Show full text]
  • Resource Management: Linux Kernel Namespaces and Cgroups
    Resource management: Linux kernel Namespaces and cgroups Rami Rosen [email protected] Haifux, May 2013 www.haifux.org 1/121 http://ramirose.wix.com/ramirosen TOC Network Namespace PID namespaces UTS namespace Mount namespace user namespaces cgroups Mounting cgroups links Note: All code examples are from for_3_10 branch of cgroup git tree (3.9.0-rc1, April 2013) 2/121 http://ramirose.wix.com/ramirosen General The presentation deals with two Linux process resource management solutions: namespaces and cgroups. We will look at: ● Kernel Implementation details. ●what was added/changed in brief. ● User space interface. ● Some working examples. ● Usage of namespaces and cgroups in other projects. ● Is process virtualization indeed lightweight comparing to Os virtualization ? ●Comparing to VMWare/qemu/scaleMP or even to Xen/KVM. 3/121 http://ramirose.wix.com/ramirosen Namespaces ● Namespaces - lightweight process virtualization. – Isolation: Enable a process (or several processes) to have different views of the system than other processes. – 1992: “The Use of Name Spaces in Plan 9” – http://www.cs.bell-labs.com/sys/doc/names.html ● Rob Pike et al, ACM SIGOPS European Workshop 1992. – Much like Zones in Solaris. – No hypervisor layer (as in OS virtualization like KVM, Xen) – Only one system call was added (setns()) – Used in Checkpoint/Restart ● Developers: Eric W. biederman, Pavel Emelyanov, Al Viro, Cyrill Gorcunov, more. – 4/121 http://ramirose.wix.com/ramirosen Namespaces - contd There are currently 6 namespaces: ● mnt (mount points, filesystems) ● pid (processes) ● net (network stack) ● ipc (System V IPC) ● uts (hostname) ● user (UIDs) 5/121 http://ramirose.wix.com/ramirosen Namespaces - contd It was intended that there will be 10 namespaces: the following 4 namespaces are not implemented (yet): ● security namespace ● security keys namespace ● device namespace ● time namespace.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Etsi Tr 103 528 V1.1.1 (2018-08)
    ETSI TR 103 528 V1.1.1 (2018-08) TECHNICAL REPORT SmartM2M; Landscape for open source and standards for cloud native software applicable for a Virtualized IoT service layer 2 ETSI TR 103 528 V1.1.1 (2018-08) Reference DTR/SmartM2M-103528 Keywords cloud, IoT, open source, virtualisation ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Containers – Namespaces and Cgroups
    Containers – namespaces and cgroups --- Ajay Nayak Motivation Why containers? • Important use-case: implementing lightweight virtualization • Virtualization == isolation of processes • Traditional virtualization: Hypervisors • Processes isolated by running in separate guest kernels that sit on top of host kernel • Isolation is “all or nothing” • Virtualization via containers • Permit isolation of processes running on a single kernel be per-global- resource --- via namespaces • Restrict resource consumption --- via cgroups Outline • Motivation • Concepts • Linux Namespaces • UTS • UID • Mount • C(ontrol) groups • Food for thought Introduction Concepts • Isolation • Goal: Limit “WHAT” a process can use • “wrap” some global system resource to provide resource isolation • Namespaces jump into the picture • Control • Goal: Limit “HOW MUCH” a process can use • A mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups • Assign specialized behaviour to the group • C(ontrol) groups jump into the picture https://github.com/nayakajay/linux-namespaces Namespaces Linux namespaces • Supports following NS types: (CLONE_FLAG; symlink) • Mount (CLONE_NEWNS; /proc/pid/ns/mnt) • UTS (CLONE_NEWUTS; /proc/pid/ns/uts) • IPC (CLONE_NEWIPC; /proc/pid/ns/ipc) • PID (CLONE_NEWPID; /proc/pid/ns/pid) • Network (CLONE_NEWNET; /proc/pid/ns/net) • User (CLONE_NEWUSER; /proc/pid/ns/user) • Cgroup (CLONE_NEWCGROUP; /proc/pid/ns/cgroup) • Time (CLONE_NEWTIME; /proc/pid/ns/time) <= very new! # Magic symlinks, which
    [Show full text]
  • Security of OS-Level Virtualization Technologies: Technical Report
    Security of OS-level virtualization technologies Elena Reshetova1, Janne Karhunen2, Thomas Nyman3, N. Asokan4 1 Intel OTC, Finland 2 Ericsson, Finland 3 University of Helsinki, Finland 4 Aalto University and University of Helsinki, Finland Abstract. The need for flexible, low-overhead virtualization is evident on many fronts ranging from high-density cloud servers to mobile devices. During the past decade OS-level virtualization has emerged as a new, efficient approach for virtualization, with implementations in multiple different Unix-based systems. Despite its popularity, there has been no systematic study of OS-level virtualization from the point of view of security. In this report, we conduct a comparative study of several OS- level virtualization systems, discuss their security and identify some gaps in current solutions. 1 Introduction During the past couple of decades the use of different virtualization technolo- gies has been on a steady rise. Since IBM CP-40 [19], the first virtual machine prototype in 1966, many different types of virtualization and their uses have been actively explored both by the research community and by the industry. A relatively recent approach, which is becoming increasingly popular due to its light-weight nature, is Operating System-Level Virtualization, where a number of distinct user space instances, often referred to as containers, are run on top of a shared operating system kernel. A fundamental difference between OS-level virtualization and more established competitors, such as Xen hypervisor [24], VMWare [48] and Linux Kernel Virtual Machine [29] (KVM), is that in OS-level virtualization, the virtualized artifacts are global kernel resources, as opposed to hardware.
    [Show full text]
  • A Research on Android Technology with New Version Naugat(7.0,7.1)
    IOSR Journal of Computer Engineering (IOSR-JCE) e-ISSN: 2278-0661,p-ISSN: 2278-8727, Volume 19, Issue 2, Ver. I (Mar.-Apr. 2017), PP 65-77 www.iosrjournals.org A Research On Android Technology With New Version Naugat(7.0,7.1) Nikhil M. Dongre , Tejas S. Agrawal, Ass.prof. Sagar D. Pande (Dept. CSE, Student of PRPCOE, SantGadge baba Amravati University, [email protected] contact no: 8408895842) (Dept. CSE, Student of PRMCEAM, SantGadge baba Amravati University, [email protected] contact no: 9146951658) (Dept. CSE, Assistant professor of PRPCOE, SantGadge baba Amravati University, [email protected], contact no:9405352824) Abstract: Android “Naugat” (codenamed Android N in development) is the seventh major version of Android Operating System called Android 7.0. It was first released as a Android Beta Program build on March 9 , 2016 with factory images for current Nexus devices, which allows supported devices to be upgraded directly to the Android Nougat beta via over-the-air update. Nougat is introduced as notable changes to the operating system and its development platform also it includes the ability to display multiple apps on-screen at once in a split- screen view with the support for inline replies to notifications, as well as an OpenJDK-based Java environment and support for the Vulkan graphics rendering API, and "seamless" system updates on supported devices. Keywords: jellybean, kitkat, lollipop, marshmallow, naugat I. Introduction This research has been done to give you the best details toward the exciting new frontier of open source mobile development. Android is the newest mobile device operating system, and this is one of the first research to help the average programmer become a fearless Android developer.
    [Show full text]