DOCSLIB.ORG

The Flask Security Architecture: System Support for Diverse Security Policies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Flask Security Architecture: System Support for Diverse Security Policies The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer (Secure Computing Corporation) Stephen Smalley, Peter Loscocco (National Security Agency) Mike Hibler, David Andersen, Jay Lepreau (University of Utah) Abstract tributed environments of today, this policy flexibility must be supported by the security mechanisms of the operating Operating systems must be flexible in their support for system [33]. security policies, providing sufficient mechanisms for sup- porting the wide variety of real-world security policies. Supporting policy flexibility in the operating system is a Such flexibility requires controlling the propagation of ac- hard problem that goes beyond just the supporting of multi- cess rights, enforcing fine-grained access rights and sup- ple policies. The system must be capable of supporting fine- porting the revocation of previously granted access rights. grained access controls on low-level objects used to per- Previous systems are lacking in at least one of these ar- form higher-level functions controlled by the security pol- eas. In this paper we present an operating systems secu- icy. Additionally, the system must ensure that the propaga- rity architecture that solves these problems. Control over tion of access rights is in accordance with the security pol- propagation is provided by ensuring that the security pol- icy. Lastly, policies are not, in general, static. To cope with icy is consulted for every security decision. Both fine- policy changes or dynamic policies, the system must have a grained access rights and revocation support are provided mechanism for the revocation of previously granted access by mechanisms that are directly integrated into the service- rights. Earlier systems have provided mechanisms that al- providing components of the system. The architecture is low several security policies to be supported, but they are described through its prototype implementation in the Flask inadequate to generally support policy flexibility because microkernel-based operating system, and the policy flexi- they fail to address at least one of these three areas. bility of the prototype is evaluated. We present initial ev- This paper describes an operating system security archi- idence that the architecture’s impact on both performance tecture that demonstrates the feasibility of policy flexibility. and code complexity is modest. Moreover, our architecture This is done by presenting its prototype implementation, is applicable to many other types of operating systems and the Flask microkernel-based operating system, that success- environments. fully overcomes these obstacles to policy flexibility. The 1 Introduction cleaner separation of mechanism and policy specified in the security architecture enables a richer set of security policies A phenomenal growth in connectivity through the Inter- to be supported with less policy-specific customization than net has made computer security a paramount concern, but has previously been possible. Flask includes a security pol- no single definition of security suffices. Different comput- icy server to make access control decisions and a framework ing environments, and the applications that run in them, in the microkernel and other object managers in the sys- have different security requirements. Because any notion of tem to enforce those access control decisions. Although the security is captured in the expression of a security policy, prototype system is microkernel-based, the security mecha- there is a need for many different policies and even many nisms do not depend on a microkernel architecture and will types of policies [1, 44, 49]. To be generally acceptable, easily generalize beyond it. any computer security solution must be flexible enough to The resulting system provides policy flexibility. It sup- support this wide range of security policies. Even in the dis- ports a wide variety of policies. It controls the propagation This research was supported in part by the Defense Advanced Re- of access rights by ensuring that the security policy, through search Projects Agency, monitored by the Department of the Army under a consistent replica, is consulted for every access deci- contract number DABT63–94–C–0058, and the Air Force Research Labo- sion. Enforcement mechanisms, directly integrated into the ratory, Rome Research Site, USAF, under agreement number F30602–96– service-providing components of the system, enable fine- 2–0269. It is also supported in part by the Maryland Procurement Office, contract MDA904-97-C-3047. grained access controls and dynamic policy support that al- Contact information: [email protected], Secure Comput- lows the revocation of previously granted access rights. Ini- ing Corp., 2675 Long Lake Road, Roseville, MN 55113-2536; sds,- tial performance results, as well as statistics on the scale pal ¡ @epoch.ncsc.mil, National Security Agency, 9800 Savage Rd, Ft and invasiveness of the code changes, indicate that the im- Meade, MD 20755-6534; pact of policy flexible security on the system can be kept to mike,danderse,lepreau ¡ @cs.utah.edu, Dept. of Computer Science, 50 S. Central Campus Drive, Rm. 3190, University of Utah, SLC, UT 84112- a minimum. 9205. http://www.cs.utah.edu/projects/flux/fluke/html/flask.html Draft, March 1999 The remainder of the paper begins by elaborating on the that may be injected by the security policy, and permits meaning of policy flexibility. After a discussion of why two some system state to exist beyond the scope of the security popular mechanisms employed in systems to provide secu- policy. In actuality, however, each of these apparent lim- rity are limiting to policy flexibility, some related work is itations is a desirable property since many of the internal described. The Flask architecture is then presented through operations and state of any system are of no apparent use or a discussion of its prototype design and implementation. concern to any security policy. Section 6.1 will discuss how The paper concludes with an evaluation of the policy flexi- these limitations were interpreted for the Flask system. bility of the system, an assessment of the performance im- A system that is policy flexible must be capable of sup- pact, and a discussion of the scale and invasiveness of the porting a wide variety of security policies. Security poli- Flask changes. cies may be classified according to certain characteristics, including such things as: the need to revoke previously 2 Policy Flexibility granted accesses, the type of input required to make access decisions, the sensitivity of policy decisions to external fac- When first attempting to define security policy flexibil- tors like history or environment, and the transitivity of ac- ity, it is tempting to generate a list of all known security cess decisions [44, Section 6]. The remainder of this section policies and define flexibility through that list. This ensures focuses on revocation, which is the most difficult of these that the definition will reflect a real-world view of the de- characteristics to support. gree of flexibility. Unfortunately, this simplistic definition is unrealistic. Real-world security polices in computer sys- Since even the simplest security policies undergo change tems are limited by the mechanisms currently provided in (e.g. as user authorizations change), a policy flexible sys- such systems, and it is not always clear how security poli- tem must be capable of supporting policy changes. Since cies enforced in the “pencil-and-paper” world translate to policy changes may be interleaved with the execution of computer systems, if at all [3, 49]. As such, a more useful controlled operations, there is the risk that the system will definition is needed. enforce access rights according to an obsolete policy. Thus, there must be an effective atomicity in the interleaving of It is more useful to define security policy flexibility by policy changes and controlled operations. viewing a computer system abstractly as a state machine performing atomic operations to transition from one state The fundamental difficulty in achieving this atomicity to the next. Within such a model, a system could be consid- is ensuring that previously granted permissions can be re- ered to provide total security policy flexibility if the security voked as required by a policy change. When a permission policy can interpose atomically on any operation performed is to be revoked, it is necessary for the system to ensure by the system, allowing the operation to proceed, denying that any service controlled by the permission will no longer the operation or even injecting operations of its own. In be provided by the system unless the permission is granted such a system, the security policy can make its decisions again later. Revocation can be a very difficult property to using knowledge of the entire current system state, where satisfy because permissions, once granted, have a tendency the current system state can be considered to encompass to migrate throughout the system. The revocation mecha- the history of the system. Because it is possible to interpose nism must guarantee that all of these migrated permissions on all access requests, it is possible to modify the existing are indeed revoked. security policy and to revoke any previously granted access. A basic example of a migrated permission surfaces in This second definition more correctly captures the Unix. The access decision for writing to a file is performed essence of policy flexibility, but practical considerations when that file is opened, and the granted permission is force a slightly more limited point of view. It is unlikely cached in the file description for efficient validation of write that a real system could base security policy decisions for access during write operations. Revoking write access to all possible operations on the entire current system state. that file in Unix only prevents future attempts to open the Instead, a more realistic approach is to identify that portion file with write access and has no effect on the migrated per- of the system state that is potentially security relevant and missions in existing file descriptions.
Load more

Recommended publications
  • Automatic Sandboxing of Unsafe Software Components in High Level Languages
    Master Thesis Automatic Sandboxing of Unsafe Software Components in High Level Languages Benjamin Lamowski Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Carsten Weinhold 3. Mai 2017 Aufgabenstellung Neue “sichere“ Programmiersprachen wie Go, Swift oder Rust wurden nicht nur für die normale Anwendungsentwicklung entworfen, sondern sie zielen auch auf eine hochper- formante Ausführung und Programmierung vergleichsweise systemnaher Funktionalität ab. Eine attraktive Eigenschaft beispielsweise von Rust ist das gegenüber C und C++ deutlich strengere Speicherverwaltungsmodell, bei dem bereits zur Kompilierzeit der Lebenszyklus und die Erreichbarkeit von Objekten sowie die Zuständigkeit für deren Allokation und Deallokation wohldefiniert sind. Ganze Klassen von Programmfehlern wie etwa Buffer Overflows oder Dereferenzierung ungültige Zeiger werden dadurch eliminiert und die Programme mithin sicherer und robuster. Aus diversen Gründen müssen Programme, die in sicheren Sprachen geschriebenen wurden, aber oftmals auf “unsicheren“ Legacy-Code zurückgreifen. So bietet etwa Rust über das “unsafe“-Sprachelement die Möglichkeit, Funktionen innerhalb von Bibliotheken aufzurufen, die in fehleranfälligem C geschrieben sind. Leider werden die vom Com- piler durchgesetzten Garantien der sicheren Sprache hinfällig, sobald im Code einer C-Bibliothek ein Speicherfehler auftritt. Ein Schreibzugriff etwa durch
    [Show full text]
  • Win32 API 1.Pdf
    Win32 Programming for Microsoft Windows NT Windows NT is designed to address the changing requirements of the computing world. It is written mainly in C and is crafted in such a way as to make its functionality extensible, and to ease the porting of the code from one hardware platform to another. This enables the ability to take advantage of multiprocessor and RISC computers, and to distribute tasks to other computers on the network, transparently. Whilst providing applications and users with the ability to use the power of local and remote machines, Windows NT must offer compatibility to applications and users. Users must feel comfortable with the interface, and be able to run existing high-volume applications. Existing applications have to port simply to the new environment to take advantage of its power. So, the user interface is compatible with existing Microsoft systems and existing programming APIs are supported and have been extended. To be considered a major player in the server arena, Windows NT has to offer reliable, robust support for ‘mission critical’ software. This means the system should be fault tolerant, protecting itself from malfunction and from external tampering. It should behave predictably and applications should not be able to adversely affect the system or each other. It should also have a security policy to protect the use of system resources, and implement resource quotas and auditing. Networking is built in, with high level programming and user interfaces available. Remote access to other machines on various networks is almost transparent. Because applications have to perform to an expected level, the system should be fast and responsive on each hardware platform.
    [Show full text]
  • Installation and Configuration Guide
    NetApp SANtricity® SMI-S Provider 11.53 Installation and Configuration Guide December 2019 | 215-13407_C0 [email protected] Table of Contents About This Guide ............................................................................................................................. 1 Overview of the NetApp SANtricity SMI-S Provider ...................................................................... 1 What’s New ................................................................................................................................1 Abbreviations, Acronyms, Terms, and Definitions ........................................................................ 1 Supported Profiles and Subprofiles ............................................................................................. 1 Supported Operating Systems for SMI-S .................................................................................... 2 Supported Firmware Versions ........................................................................................................ 3 System Requirements ..................................................................................................................... 3 Installing and Uninstalling SMI-S Provider ..................................................................................... 4 Windows operating system install and uninstall process ............................................................... 4 Installing SMI-S Provider (Windows operating system) .....................................................
    [Show full text]
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • Windows Kernel Hijacking Is Not an Option: Memoryranger Comes to The
    WINDOWS KERNEL HIJACKING IS NOT AN OPTION: MEMORYRANGER COMES TO THE RESCUE AGAIN Igor Korkin, PhD Independent Researcher Moscow, Russian Federation [email protected] ABSTRACT The security of a computer system depends on OS kernel protection. It is crucial to reveal and inspect new attacks on kernel data, as these are used by hackers. The purpose of this paper is to continue research into attacks on dynamically allocated data in the Windows OS kernel and demonstrate the capacity of MemoryRanger to prevent these attacks. This paper discusses three new hijacking attacks on kernel data, which are based on bypassing OS security mechanisms. The first two hijacking attacks result in illegal access to files open in exclusive access. The third attack escalates process privileges, without applying token swapping. Although Windows security experts have issued new protection features, access attempts to the dynamically allocated data in the kernel are not fully controlled. MemoryRanger hypervisor is designed to fill this security gap. The updated MemoryRanger prevents these new attacks as well as supporting the Windows 10 1903 x64. Keywords: hypervisor-based protection, Windows kernel, hijacking attacks on memory, memory isolation, Kernel Data Protection. 1. INTRODUCTION the same high privilege level as the OS kernel, and they also include a variety The security of users’ data and of vulnerabilities. Researchers applications depends on the security of consider that “kernel modules (drivers) the OS kernel code and data. Modern introduce additional attack surface, as operating systems include millions of they have full access to the kernel’s lines of code, which makes it address space” (Yitbarek and Austin, impossible to reveal and remediate all 2019).
    [Show full text]
  • On the Construction of Reliable Device Drivers Leonid Ryzhyk
    On the Construction of Reliable Device Drivers Leonid Ryzhyk Ph.D. 2009 ii iii ‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously pub- lished or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this the- sis is the product of my own work, except to the extent that as- sistance from others in the project’s design and conception or in style, presentation, and linguistic expression is acknowledged.’ Signed .................................. Date .................................. iv Abstract This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing sig- nificant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks.
    [Show full text]
  • Building a Reliable Storage Stack
    Building a Reliable Storage Stack Ph.D. Thesis David Cornelis van Moolenbroek Vrije Universiteit Amsterdam, 2016 This work was supported by the European Research Council Advanced Grant 227874. This work was carried out in the ASCI graduate school. ASCI dissertation series number 355. Copyright © 2016 by David Cornelis van Moolenbroek. ISBN 978-94-028-0240-5 Cover design by Eva Dienske. Printed by Ipskamp Printing. VRIJE UNIVERSITEIT Building a Reliable Storage Stack ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. V. Subramaniam, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Exacte Wetenschappen op maandag 12 september 2016 om 11.45 uur in de aula van de universiteit, De Boelelaan 1105 door David Cornelis van Moolenbroek geboren te Amsterdam promotor: prof.dr. A.S. Tanenbaum To my parents Acknowledgments This book marks the end of both a professional and a personal journey–one that has been long but rewarding. There are several people whom I would like to thank for accompanying and helping me along the way. First and foremost, I would like to thank my promotor, Andy Tanenbaum. While I was finishing up my master project under his supervision, he casually asked me “Would you like to be my Ph.D student?” during one of our meetings. I did not have to think long about the answer. Right from the start, he warned me that I would now have to conduct original research myself; only much later did I understand the full weight of this statement.
    [Show full text]
  • Free Software Philosophy, History and Practice
    Introduction (and some quick reminders) History and philosophy Legal aspects Free Software Philosophy, history and practice Luca Saiu [email protected] http://ageinghacker.net GNU Project Screencast version Paris, October 2014 Luca Saiu <[email protected]> Free Software — Philosophy, history and practice Introduction (and some quick reminders) History and philosophy Legal aspects Introducing myself I’m a computer scientist living and working somewhere around Paris... ...and a GNU maintainer. I’m also an associate member of the Free Software Foundation, a fellow of the Free Software Foundation Europe and an April adherent. So I’m not an impartial observer. Luca Saiu <[email protected]> Free Software — Philosophy, history and practice Introduction (and some quick reminders) History and philosophy Legal aspects Contents 1 Introduction (and some quick reminders) 2 History and philosophy The hacker community The GNU Project and the Free Software movement Linux and the Open Source movement 3 Legal aspects Copyright Free Software licenses Luca Saiu <[email protected]> Free Software — Philosophy, history and practice Introduction (and some quick reminders) History and philosophy Legal aspects Reminders about software — source code vs. machine code Source code vs. machine code Quick demo Luca Saiu <[email protected]> Free Software — Philosophy, history and practice Programs are linked to libraries static libraries shared libraries Libraries (or programs) request services to the kernel Programs invoke with other programs Programs communicate with other programs... ...on the same machine ...over the network We’re gonna see that this has legal implications. Introduction (and some quick reminders) History and philosophy Legal aspects Reminders about software — linking In practice, programs don’t exist in isolation.
    [Show full text]
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen- erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli- this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga- mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac- Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi- of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu- the security policy is consulted for every security deci- rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor- the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Microkernels Meet Recursive Virtual Machines
    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract ªverticallyº by implementing OS functionalityin stackable virtual machine monitors, each of which exports a virtual Thispaper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally,virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support ªnaiveº operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ®ciently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; ef®ciency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more ef®ciently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
    [Show full text]
  • Executive Summary
    Mobile Commerce Security: Legal & Technological Perspectives Michael Triguboff Table of Contents EXECUTIVE SUMMARY 4 INTRODUCTION 7 The Need for Security 11 PART I TECHNOLOGY 12 Client-Side Vulnerabilities 12 Browser Software 13 Java Applets 14 ActiveX controls 16 JavaScript 18 Plug-Ins and Graphic Files 18 Push technology 18 Web Server Security 19 Front-end 20 Firewalls 22 Back-end Database vulnerabilities 23 Server- Side Middleware 24 Operating System Problems 25 Hardened versions of Operating Systems 36 Distributed systems 37 Software Testing 38 Mobile Commerce Issues 43 Device Properties 43 Wireless Communication 45 Wireless Communication Protocols 47 Ad Hoc Networks 49 Ad Hoc Networks and Key Management 51 Network Protection in Ad Hoc Networks 54 Location Dependent Information and Mobile Computing 55 Mobile Agents 56 Protecting the Host from the Mobile Agent 59 Safe Code Interpretation 61 Digital Signatures 63 Proof Carrying Code 63 Path Histories 64 Software-Based Fault Isolation [“Sandboxing”] 64 Protecting the Agent From the Host and Other Agents 64 Secure Control of Remote Agents 65 Read-Only/Append-Only 65 Partial Results Encapsulation 66 Code Obfuscation 67 Computing with Encrypted Functions 67 Environmental Key Generation 68 Execution Tracing 68 Itinerary Recording 69 Security Through Shared Secrets and Interlocking 69 Other Approaches 69 Attacks Based on Device Limitations 71 2 Prevention, Detection and Reaction 71 Intrusion Detection 72 Intrusion Detection and Mobile Agents 75 Part I Conclusion 76 PART 11 THE LEGAL PERSPECTIVE 80 The Debate: A Confluence of Two Streams 81 Uniform Electronic Transactions Act 85 Article 2B of the Uniform Commercial Code 85 The Electronic Signatures in Global and National Commerce Act [“E-Sign Act”] 88 Jurisdiction Selection 90 Reaction- Criminal Law 96 Convention on Cyber-Crime 97 Evidentiary or Procedural Law 99 Practical Considerations 100 Part II Conclusion 101 APPENDIX 103 Digital Millennium Copyright Act 103 BIBLIOGRAPHY 107 3 EXECUTIVE SUMMARY The objectives of this project are twofold.
    [Show full text]