Embed Size (px)
Citation preview
Introduction
• Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered.
• All sorts of code should be signed, including tools, applications, scripts, libraries, plug-ins, and other “code-like” data.
2
Targets
• Ensure the integrity of the code; that it has not been altered.
• Identify the code as coming from a specific source (the vendor or signer).
• Determine whether the code is trustworthy for a specific purpose (for example, to access a keychain, or parent control).
3
Signed Code Includes
• A unique identifier, used to identify the code or to determine to which groups or categories the code belongs.
• A collection of checksums of the various parts of the program, such as the identifier, the main executable, the resource files.
• A digital signature, which signs the seal to guarantee its integrity.
4
What It can do
• Content Source: End users can confirm that the software really comes from the publisher who signed it.
• Content Integrity: End users can verify that the software has not been altered or corrupted since it was signed.
5
What It cannot do
• It can’t guarantee that the code is free of security vulnerabilities.
• It can’t guarantee that a program will not load unsafe or altered code—such as untrusted plug-ins—during execution.
• It can’t determine how much to “trust” the code.
• Attacks from administrator.
6
Other Disadvantages
• The user is likely to be bothered with additional dialog boxes and prompts for unsigned code that they don’t see with signed code, and unsigned code might not work as expected with some system components.
• Computation and storage overhead.
7
Architecture
exec()
sys_execve()
LSM Hook CodesignKernel Module
CodesignUser-spaceDaemon
Netlink Socket
True/False
mmap()
Enterprise Architecture
CheckEngine
Intranet
Policy DB
Kernel Module
Daemon
Host
Kernel Module
Daemon
Host
Kernel Module
Daemon
Host
host root host root host root
enterprise admin
Components
• Codesign Tool: used to create, check, and display code signatures.
• Kernel Module: Implement LSM (Linux Security Module) hook to check the signature in ELF.
• User-space Daemon: Do the checking, called by kernel module.
10
User vs Kernel
What user-space daemons can do but kernel modules cannot:
• Perform a long-running computation, block while waiting for an event;
• Access file system, network and devices;
• Get interactive input from user or pop up GUI windows
11
User & Kernel
• Splitting the implementation between kernel and user space is quite common in Linux.
• Only the most essential and performance-critical code are placed in the kernel.
• Other things, such as GUI, management and control code, typically are programmed as user-space applications.
12
How to Communicate?
• IPC between kernel and user space:
- system calls,
- ioctl
- proc filesystem
- netlink socket
13
Netlink Socket
• Full-duplex communication link by way of standard socket APIs for user-space processes and a special kernel API for kernel modules.
• Address family AF_NETLINK (include/linux/netlink.h).
14
User-Space APIs
• to do: standard socket API
15
Kernel-Space APIs
• To do: view the kernel code.
16
Linux Security Module
• Linux Security Module (LSM) is a general access-control framework of kernel hooks that would allow security models to work as loadable kernel modules.
• This approach would allow different security models to work togethor without modifying the main kernel code.
17
Executables
• Binary Executables:
• ELF (Executables and Linkable Format),
• A.out (Assamby OUT put format),
• COFF (Common Object File Format).
• Java bytecode, scripts and other loadable modules.
18
ELF Format
• Relocatable file (.a)
• Shared object file (.so)
• Executable file (binary)
ELF Header
Program Header Table
Text Segment
Data Segment
BSS Segment
".symtab" section
Section Header Table
Deployment
• Apply a code signing identity and cpk private key.
• Sign all trusted binaries and libraries with codesign toolkit.
• Modify the system startup procedure to load code signing module.
20
Our Works
• Learn details of ELF format and how to insert a signature into a ELF executable or a dynamic library?
• Learn code signing related LSM API or related kernel procedures of other OSs.
• Learn how to access a user-space daemon from kernel module.
• Learn details of deployment.
21
Our Works (cont.)
• How to trust a signature, some factors need to be considered:
• domain,
• vendor,
• product,
• user.
22
Schneier’s Arguments
• Users have no idea how to decide if a particular signer is trusted or not.
• Just because a component is signed doesn't mean that it is safe.
• Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.
23
Related Projects
• Umbrela
• Bsign (Debian): Signed SHA1 inserted into ELF header.
• DigSig (Ericsson Research Lab): Kernel module for checking BSign signatures.
• Tripwire (Tripwire Inc.):Intrusion detection with file system hashes.
24
References
• http://ask.slashdot.org/article.pl?sid=05/08/31/2045201
• http://users.tkk.fi/~jpkarna/papers/sign.html
• http://sourceforge.net/projects/umbrella
• MSDN: Digital Code Signing Step-by-Step Guide
25
Reference (cont.)
• Microsoft Authenticode Digital ID Instructions － the official guide by VeriSign
• Signing and Checking Code with Authenticode - MSDN
• Signing a XPI - Mozilla
• Code Signing Guide - Apple
26
Linux Security Module Framework
Introduction
• Linux Security Module (LSM) provides Linux kernel with a general purpose framework for access control.
Related Work
Related Work
• POSIX.1e capabilities
• Security Enhanced Linux (SELinux)
• Domain and Type Enforcement (DTE)
• Linux Intrusion Detection System (LIDS)
Design Principles
• truly generic, where using a different security model is merely a matter of loading a different kernel module;
• conceptually simple, minimally invasive, and efficient; and
• able to support the existing POSIX.1e capabilities logic as an optional security module.
User Level Process
User Level Process
Look up inode
Error checks
DAC checks
LSM hook
Complete request
inode
User Space
Kernel Space
Examine contextDoes request pass policy?
Grant or deny
LSM ModulePolicy Engine
access
LSM Hook Architecture
Yes or No
OK with you?
Program Loading
• linux_binprm : Linux binary program
• binprm_security_ops
• include/linux/security.h
