Implementation of XATTR on JFFS2 and SELinux CE Linux Forum Technical Jamboree(Oct 27, 2006) Kohei Kaigai, OSS Promotion Center, NEC [translated by ikoma; see original slides for figures] ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 2 Contents * Introduction <== * Structure of XATTR/JFFS2 * Feedback from the Community * Use of XATTR/JFFS2 and Future Works ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 3 Who on earth am I? * Developing around SELinux - Improved scalability of SELinux (2004) + SELinux then was slow + Realized lockless reference using RCU - Supported XATTR on JFFS2 (2005-2006) <== + JFFS2 = Filesystem for Flash ROM + To use SELinux, XATTR must be supported - Developing PostgreSQL for SELinux (in progress) + Information flow control integrated with OS ---------------------------- = ---------------------------- [see original slide; page 4] Copyright (C) 2006, NEC Corporation 4 In the first place, what is SELinux? (1) user space process A process B system calls read() write() ioctl() xxx() kernel space vfs_read() function LSM hook What about read? - OK sys_ioctl() function LSM hook What about ioctl? - NG SELinux security policy’¡Êpolicydb’¡Ë * Check if executable at system call execution * Even root checked (=mandaotory access control) * Rules managed in integrated manner with security policy * TE/RBAC/MLS features offered ---------------------------- = ---------------------------- [see original slide; page 5] Copyright (C) 2006, NEC Corporation 5 In the first place, what is SELinux? (2) signal process A unconfined_t read getattr ioctl file X user_home_t type file Y user_home_t getattr process B postgresql_t read getattr ioctl write file Z postgresql_db_t *security policy* allow unconfined_t user_home_t:file {read getattr ioctl}; allow unconfined_t postgresql_db_t:file {getattr}; allow postgresql_t postgresql_db_t: file {read getattr ioctl write}; allow unconfined_t postgresql_t:process {signal}; Give types to all process resources => Enforcement of "type", i.e. TE(Type Enforcement) ---------------------------- = ---------------------------- [see original slide; page 6] Copyright (C) 2006, NEC Corporation 6 In the first place, what is XATTR? * XATTR=eXtended ATTRribute hello.c (contents) #include int main(){ puts("hello world!"); } (attributes) owner: kaigai group:users permission:0755 file size 123 bytes last update: 10/28 10:11:22 ’¡§ (extended attributes(XATTR)) security.selinux -- name = user_u:object_r:user_home_t:s0 -- value system.posix_acl_access = u:rw-:ymj -- any value can be stored with any name ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 7 Support of XATTR for JFFS2 - development started (1) - * Intimacy between embedded systems and SELinux -- Even if security patch released -> there are cases where patches cannot be applied immediately -- A huge volume of machines of identical configuration released into market -> Threat of 0-day attack is unpredictable -- Directly connected to threat against life/property * Then, what is necessary? -- Busybox commands for SELInux -- Reduction of security policy size -- XATTR support for diskless file system <- ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 8 Support of XATTR for JFFS2 - development started (2) - * What is the development trends in original community? - Asked actually at Jul, 2005 Ottawa Linux Symposium Stephen Smalley says: 1. For busy box, Cocker's patch should be available 2. For smaller policy size, just now developing 3. Somebody seems to have implemented XATTR for JFFS2 using hidden files David Woodhouse says: No plan now to implement XATTR for JFFS2; contribution would be welcome ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 9 XATTR Status (Kernel 2.6.18) * For servers/workstations - Ext2, Ext3, XFS, ReiserFS, JFS * For embedded systems - JFFS2 (Added in kernel 2.6.18) + Filesystem developed to use Flash ROM etc. effectively + Design taking account of robustness and lifetime of media * Network filesystem - NFSv3, NFSv4, CIFS (But supporting only POSIX-ACL) * Pseudo-filesystem - FUSE ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 10 Contents * Introduction * Structure of XATTR/JFFS2 <== * Feedback from the Community * Use of XATTR/JFFS2 and Future Works[see original slide; page 11] ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 11 What filesystem is JFFS2 like? (1) * Features of Flash ROM - Recognized as MTD device - Limited number of writing: Around 100 thousand times - Data once wrinten can only be erased as an Erase Block * Features of JFFS2 - Implemented as a upper layer of MTD device - Designed not to heavily use particular area on the media (Write-once-like architecture) - Garbage collector reallocates data on media, allowing to erase per Erase Block [figure] Erase Block Total amount ---------------------------- = ---------------------------- [see original slide; page 12] Copyright (C) 2006, NEC Corporation 12 What filesystem is JFFS2 like? (2) Write-once-like architecture Writing unit: node * Recordable in arbitary length * Checing consistensy with CRC code * 7 types including inode type JFFS2_NODETYPE_INODE JFFS2_NODETYPE_DIRENT JFFS2_NODETYPE_CLEANMARKER JFFS2_NODETYPE_PADDING JFFS2_NODETYPE_SUMMARY JFFS2_NODETYPE_XATTR JFFS2_NODETYPE_XREF Node common header 32bit +---------------------+---------------------+ +0 | JFFS2_MAGIC_BITMASK | node type | +---------------------+---------------------+ +4 | Total Length | +-------------------------------------------+ +8 | Header CRC Code | +-------------------------------------------+ ---------------------------- = ---------------------------- [see original slide; page 13] Copyright (C) 2006, NEC Corporation 13 What filesystem is JFFS2 like? (3) want to update here: inode no.: 123 version no.: 1 inode no.: 123 version no.: 2 inode no.: 123 version no.: 3 * update = increment version number + append * There are more than one nodes with an identical inode No. and different version No. * Nodes with older version No. are ignored -> Later collected by GC and the region becomes available again after Erase Blocks deleted ---------------------------- = ---------------------------- [see original slide; page 14] Copyright (C) 2006, NEC Corporation 14 What filesystem is JFFS2 like? (4) Getting tight Append (copy) to Erase Blocks for save GC:Garbage Collector Delete the Erase Block in a lump ---------------------------- = ---------------------------- [see original slide; page 15] Copyright (C) 2006, NEC Corporation 15 What filesystem is JFFS2 like? (5) All media scanned when mounted ino=123 version=1 (dead) ino=123 version=2 (dead) ino=123 version=3 (alive) EBS(Erase Block Summary) feature Just reading Summary at the end of Erase Blocks tells which kinds of nodes are written where =>Faster mounting ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 16 What filesystem is JFFS2 like? (6) * Write-once-like architcture -- Not use heavily a specific area on media -> long lasting! -- GC reallocates nodes, based on the characteristics of Flash-ROM * Robustness -- No Super Block at specific location -- CRC checked while reading data * There is a drawback: -- Must scan whole media when mounting FS + EBS (Erase Block Summary) support remedys the situation ---------------------------- = ---------------------------- [see original slide; page 17] Copyright (C) 2006, NEC Corporation 17 Basic Structure of XATTR on JFFS2 (1) * Definition of node types storing XATTR JFFS_NODETYPE_XATTR node 32bit +---------------------+-----------------------+ +0 | JFFS2_MAGIC_BITMASK | JFFS2_NODETYPE_XATTR | +---------------------+-----------------------+ +4 | Total Length | +---------------------------------------------+ +8 | Header CRC Code | +---------------------------------------------+ +12 | XID(XATTR Identifier) | +---------------------------------------------+ +16 | Version no. | +----------+----------+-----------------------+ +20 | xprefix | Name Len | Data Len | +----------+----------+-----------------------+ +24 | Data CRC Code | +---------------------------------------------+ +28 | Node CRC Code | +---------------------------------------------+ | XATTR Name/Value pair | | | Name Len + Data Len + 1 | +-------------+ | | Padding | +-------------------------------+-------------+ JFFS2_NODETYPE_XREF node 32bit +---------------------+-----------------------+ +0 | JFFS2_MAGIC_BITMASK | JFFS2_NODETYPE_XREF | +---------------------+-----------------------+ +4 | Total Length | +---------------------------------------------+ +8 | Header CRC Code | +---------------------------------------------+ +12 | inode no. | +---------------------------------------------+ +16 | XID(XATTR Identifier) | +-------------------------------------------+-+ +20 | xseqno(XATTR Sequencial Number) |*| <--Delete Marker +-------------------------------------------+-+ +24 | Node CRC Code | +---------------------------------------------+ ---------------------------- = ---------------------------- [see original slide; page 18] Copyright (C) 2006, NEC Corporation 18 Basic Structure of XATTR on JFFS2 (2) inode ino=160 /etc/shadow ino=110 /bin/ps ino=101 /bin/cat ino=119 /bin/vi xref XREF ino=160 XID=95 XREF ino=160 XID=80 XREF ino=110 XID=60 XREF ino=101 XID=60 XREF ino=119 XID=60 xattr XID=80 security.selinux = system_u:object_r:shadow_t:s0 XID=60 security.selinux = system_u:object_r:bin_t:s0 XID=95 system.posix_acl_access = user:kaigai:r-- ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 19 Basic Structure of XATTR on JFFS2 (3) * inode and xattr have N:M relation -- More than one inode shares name/value pairs of xattr -- Efficient storage/memory usage * Keeps existing node structure -- Just ignored as "unknown node" on old kernel * Can store: -- SELinux label (security.*) -- POSIX ACL (system.posix_acl_{accessúUdefault}) -- Arbitary user type data (user.*, trusted.*) ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 20 Approaches proposed so far * Method using hidden file -- By Lorenzo Herna'ndez Garci'a-Hierro -- Same way as used in ReiserFS * Given up because it is on the JFFS3 roadmap & bugs cannot be cleaned up * Extension to directory entry -- By Ma Yun -- Posted just 6 hours before I posted patch (It was lucky that this was not a patent) -- Put Name/Value pairs of XATTR into directory entry * Cannot share the same Name/Value pair * In SELinux, a lot of same Name/Value pairs are used * Undesirable to change meaning of JFFS2_NODETYPE_DIRENT node ---------------------------- = ---------------------------- [see original slide; page 21] Copyright (C) 2006, NEC Corporation 21 Data Structure of XATTR on JFFS2 (1) jffs2_xattr_datum object XID=123, version=8 node xname/xvalue Name/Value pair security.selinux = system_u:object_r:... jffs2_raw_node_ref object offset next_in_ino jffs2_raw_node_ref object offset next_in_ino 1 to 1 correspondence to node on media jffs2_raw_node_ref object offset next_in_ino kernel memory space --------------------- format on media XID=123 version=7 system_u:object_r:... XID=123 version=6 system_u:object_r:... XID=123 version=8 system_u:object_r:... jffs2_raw_xattr struct defines format ---------------------------- = ---------------------------- [see original slide; page 22] Copyright (C) 2006, NEC Corporation 22 Data Structure of XATTR on JFFS2 (2) jffs2_xattr_ref object node ic xd jffs2_inode_cache object ino=321 jffs2_xattr_datum object XID=123 jffs2_raw_node_ref object offset next_in_ino jffs2_raw_node_ref object offset next_in_ino jffs2_raw_node_ref object offset next_in_ino kernel memory space --------------------- format on media ino=321 XID=123 xseqno=1018 ino=321 XID=123 xseqno=1016 ino=321 XID=123 xseqno=1020 jffs2_raw_xref struct defines format ---------------------------- = ---------------------------- [see original slide; page 23] Copyright (C) 2006, NEC Corporation 23 Data Structure of XATTR on JFFS2 (3) jffs2_inode_cache object ino=321 node xref jffs2_xattr_ref object jffs2_xattr_ref object jffs2_xattr_ref object jffs2_raw_node_ref object offset next_in_ino jffs2_raw_node_ref object offset next_in_ino jffs2_raw_node_ref object offset next_in_ino kernel space -------------------------- format on media ino=321 version=7 system_u:object_r:... ino=321 version=6 system_u:object_r:... ino=321 version=8 system_u:object_r:... jffs2_raw_inode struct defines format ---------------------------- = ---------------------------- [see original slide; page 24] Copyright (C) 2006, NEC Corporation 24 Data Structure of XATTR on JFFS2 (4) getxattr(file, xname, buffer, size) user space ----------------- kernel space VFS vfs_getxattr(dentry, xname, buffer, size) inode_operation->getxattr generic_getxattr(dentry, xname, buffer, size) do_jffs2_getxattr(inode, xprefix, xname, buffer, size) jffs2_inode_cache object jffs2_xattr_ref jffs2_xattr_datum Name/Value pair jffs2_xattr_ref jffs2_xattr_datum Name/Value pair jffs2_xattr_ref jffs2_xattr_datum Name/Value pair search Name/Value pair matching to xname ---------------------------- = ---------------------------- [see original slide; page 25] Copyright (C) 2006, NEC Corporation 25 Data Structure of XATTR on JFFS2 (5) ’£Ç’£Ã scan jffs2_raw_node_ref jffs2_raw_node_ref jffs2_raw_node_ref jffs2_inode_cache or jffs2_xattr_datum or jffs2_xattr_ref ?????? reference required in direction node -> inode/xattr/xref save_xattr_datum() save_xattr_ref() jffs2_raw_node_ref jffs2_raw_node_ref jffs2_raw_node_ref struct jffs2_raw_node_ref { struct jffs2_raw_node_ref * next_in_ino; uint32_t flash_offset; }; ---------------------------- = ---------------------------- [see original slide; page 26] Copyright (C) 2006, NEC Corporation 26 Data Structure of XATTR on JFFS2 (6) jffs2_inode_cache struct +----------------------------------------------+ | void *always_null; | +----------------------------------------------+ | struct jffs2_raw_node_ref *nodes; | +-----------+-----------+----------------------+ | u8 class; | u8 flags; | u16 state; | +-----------+-----------+----------------------+ | u32 ino; | +----------------------------------------------+ RAWNODE_CLASS_INODE_CACHE jffs2_xattr_datum struct +----------------------------------------------+ | void *always_null; | +----------------------------------------------+ | struct jffs2_raw_node_ref *nodes; | +-----------+-----------+----------------------+ | u8 class; | u8 flags; | u16 xprefix; | +-----------+-----------+----------------------+ | struct list_head xindex; | +----------------------------------------------+ RAWNODE_CLASS_XATTR_DATUM jffs2_xattr_ref struct +----------------------------------------------+ | void *always_null; | +----------------------------------------------+ | struct jffs2_raw_node_ref *nodes; | +-----------+-----------+----------------------+ | u8 class; | u8 flags; | u16 unused; | +-----------+-----------+----------------------+ | u32 xseqno; | +----------------------------------------------+ RAWNODE_CLASS_XATTR_REF * Many of jffs2_raw_node_ref objects are generated -- Not allowed to increase the size of struct * Head part of the structure is a common format -- Seeing class variable can tell the type of the object -- Area obtained by reducing state variable originally of 32 bit width into 16 bits -> size of jffs2_inode_cache struct increased only size of pointer to jffs2_xattr_ref (+4 bytes) -- Most processing of garbage collector can be refactored ---------------------------- = ---------------------------- [see original slide; page 27] Copyright (C) 2006, NEC Corporation 27 Processing when Mounted (1) scan through media XID=123 version=4 XID=123 version=5 XID=123 version=6 Node with the largest version no. is the right one EBS(Erase Block Summary) Feature Writes contents to be scanned into at the end of each Erase Block beforehand -> Just read here -> Faster mouting time Merged into the mainline ahead while developing xattr So XATTR had to support this ---------------------------- = ---------------------------- [see original slide; page 28] Copyright (C) 2006, NEC Corporation 28 Processing when Mounted (2) jffs2_xattr_datum (Loaded state) Name/Value pair --unload_xattr_datum()--> <--load_xattr_datum()-- jffs2_xattr_datum (Unloaded state) do_verify_xattr_datum() function jffs2_xattr_datum (unverified state) * XATTR marker(16bit) * XID(32bit) * version no.(32bit) * offset(32bit) * node length(32bit) XATTR info included in summary ’¡¡’¡¡ jffs2_sum_xattr_flush +0’¡¡+------------------------+ | nodetype | +2’¡¡+------------------------+ | XID | +6’¡¡+------------------------+ | version | +10 +------------------------+ | offset | +14 +------------------------+ | totlen | +18 +------------------------+ ’¡¡’¡¡jffs2_sum_xref_flush +0’¡¡+------------------------+ ’¡¡’¡¡| nodetype | +2’¡¡+------------------------+ ’¡¡’¡¡| offset | +6 +------------------------+ ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 29 Contents * Introduction * Structure of XATTR/JFFS2 * Feedback from the Community <== * Use of XATTR/JFFS2 and Future Works ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 30 Processing when to Delete Nodes (1) * In earlier implementations (-revision.5) by Kaigai: -- xattr_datum and xattr_ref always has single node -- When to delete node, overwrites node header with 0xff -- Somebody pointed out that this can not be used with NAND flash memory * Changed to implementation using "delete marker" (revision.6) -- Mark the node with the largest version no. as "This XATTR has been deleted" -- This XATTR will be skipped when mounted next time * Issue of atomicity of XATTR deletion * XATTR which has been set is treated as "deleted" ---------------------------- = ---------------------------- [see original slide; page 31] Copyright (C) 2006, NEC Corporation 31 Processing when to Delete Nodes (2) * Issue of atomicity of XATTR deletion -- Modified to treat as "deleted" XATTR not referenced from any inode Processing to delete XATTR Write out JFFS2_NODETYPE_XATTR with deletion marker Write put JFFS2_NODETYPE_XREF with deletion marker * Before writing out XREF, - what if media becomes full? - what if OS crashes? JFFS2 anyway scans all nodes on the media when mounted -> Use "number of XREFs referring to XATTR" as "deleted flag" ---------------------------- = ---------------------------- [see original slide; page 32] Copyright (C) 2006, NEC Corporation 32 Processing when to Delete Nodes (3) * Written XATTR treated as "deleted" Write name="security.selinux"value="system_u:..." to ino=200 Name/Value pair exists on XATTR cache NO(XID=123) Write JFFS2_NODETYPE_XATTR(XID=123) YES(XID=123) Write JFFS2_NODETYPE_XREF(ino=200, XID=123) 1. Remove XATTR(XID=123) from inode 2. As the XATTR is shared, it is not removed at this timing 3. Set the identical Name/Value pair -> Generate XREF with same ino/xid combination Who owns the version no.? -> If version no. specific to XREF is used, "deleted" one may be judged to be newer So, give a globally unique sequence number (xseqno/31bit) ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 33 David Woodhouse's Refactoring * Size of jffs2_raw_node_ref reduced (16bytes->8bytes) -- Interface to get physical node modified * Format of jffs2_inode_cache modified -- GC implementation refactored among inode/xattr/xref -> David Woodhouse: Inode part modified, so please modify xattr/xref implementation accordingly to new format Now becomes coding with clearer view of entire filesystem ---------------------------- = ---------------------------- [see original slide; page 34] Copyright (C) 2006, NEC Corporation 34 Garbage Collection (1) jffs2_reserve_space() Available area is less than requested jffs2_garbage_collect_pass() jffs2_garbage_collect_trigger() Available block number : 2%-3% Garbage Collector (jffs2_gcd_mtd0) kernel_thread() mount scan jffs2_raw_node_ref offset next_in_ino non-NULL NULL jffs2_inode_cache or jffs2_xattr_datum or jffs2_xattr_xref Identifiable with member variable "class" ---------------------------- = ---------------------------- [see original slide; page 35] Copyright (C) 2006, NEC Corporation 35 Garbage Collection (2) jffs2_raw_node_ref ic/xd/xref Up to here, common processing path both for inode and for XATTR jffs2_xattr_datum Yes Is the node Latest? Yes jffs2_garbage_collect_xattr_datum() => save_xattr_datum() Write XATTR into a new block No No jffs2_xattr_ref Yes Is the node Latest? Yes jffs2_garbage_collect_xattr_ref() => save_xattr_ref() Write XREF into a new block Increment version no. No No jffs2_garbage_collect_live() Garbage collection of JFFS2_NODETYPE_INODE JFFS2_NODETYPE_DIRENT ---------------------------- = ---------------------------- [see original slide; page 36] (C) 2006, NEC Corporation 36 Garbage Collection (3) jffs2_xattr_datum and jffs2_xattr_ref can not be freed immediately XID=100 version=4 XID=100 version=6 XID=100 version=9 (Latest) XID=100 version=5 Refers to jffs2_xattr_datum object to judge if garbage jffs2_xattr_datum XID=100 (JFFS2_XFLAGS_DEAD) <- Flag meaning that "it is not referred from anywhere" jffs2_free_jeb_node_refs() (processing just before deleting Erase Block) jffs2_raw_node_ref Node included in Erase Block ic/xd/xref Common processing path both for inode and for XATTR XATTR? Yes jffs2_release_xattr_datum() No XREF? Yes jffs2_release_xattr_ref() No jffs2_del_ino_cache() ---------------------------- = ---------------------------- [see original slide; page 37] Copyright (C) 2006, NEC Corporation 37 Garbage Collection (3) jffs2_xattr_datum and jffs2_xattr_ref can not be freed As all referring nodes deleted, now can be freed jffs2_xattr_datum XID=100 (JFFS2_XFLAGS_DEAD) <- Flag meaning that "it is not referred from anywhere" jffs2_free_jeb_node_refs() (processing just before deleting Erase Block) jffs2_raw_node_ref Node included in Erase Block ic/xd/xref Common processing path both for inode and for XATTR XATTR? Yes jffs2_release_xattr_datum() No XREF? Yes jffs2_release_xattr_ref() No jffs2_del_ino_cache() ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 38 Isn't it Redundant? * Length restriction of XATTR Name/Value pair #define XATTR_NAME_MAX 255 #define XATTR_SIZE_MAX 65536 -- In XATTR/JFFS2, dependent on EraseBlock size ’¡ÊNOR-Flash’¡§64KB-128KB’¡¢NAND Flash’¡§8KB-16KB’¡Ë -- "Can not implement XATTR spanning over more than one nodes?" -- "Is it really necessary!?" * About 100 bytes at most are enough for SELinux or POSIX-ACL * Total size of XATTR in Ext2/3 is Block Size (4K bytes) -- "Seems reasonable when Ext2/3 requires such" ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 39 XATTR/JFFS2 Merged in Kernel 2.6.18 And total 20 patches are merged in kernel 2.6.18 as XATTR/JFFS2 implementation [JFFS2][XATTR] Fix memory leak in POSIX-ACL support [JFFS2][XATTR] Fix xd->refcnt race condition [JFFS2][XATTR] coexistence between xattr and write ... [JFFS2][XATTR] Fix wrong copyright [JFFS2][XATTR] Re-define xd->refcnt as atomic_t [JFFS2][XATTR] Fix memory leak with jffs2_xattr_ref [JFFS2][XATTR] rid unnecessary writing of delete marker. [JFFS2][XATTR] Fix ACL bug when updating null xattr ... [JFFS2][XATTR] using 'delete marker' for xdatum/xref ... [JFFS2][XATTR] Fix obvious typo [JFFS2][XATTR] Handling the duplicate JFFS2_NODETYPE ... [JFFS2][XATTR] remove redundant pointer cast in acl.c [JFFS2][XATTR] remove '__KERNEL__' from acl.h [JFFS2][XATTR] remove senseless comment [JFFS2][XATTR] Unify each file header part with any ... [JFFS2][XATTR] '#include ' was added ... [JFFS2][XATTR] Remove jffs2_garbage_collect_xattr(c, ic) [JFFS2][XATTR] Remove 'struct list_head ilist' from ... [JFFS2][XATTR] Add a description about c->xattr_sem [JFFS2][XATTR] remove typedef from posix_acl related ... [JFFS2][XATTR] XATTR support on JFFS2 (version. 5) ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 40 Contents * Introduction * Structure of XATTR/JFFS2 * Feedback from the Community * Use of XATTR/JFFS2 and Future Works <== ---------------------------- = ---------------------------- [see original slide; page 41] Copyright (C) 2006, NEC Corporation 41 Installed SELinux on OpenZaurus Security contexts are displayed kernel: 2.6.16-oz + KaiGai patch Policy: SPDL(Simplified Policy) libselinux, libsepol, /sbin/init, busybox etc. are installed. ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 42 OLPC(One Laptop Per Child) Project * PCs for children in developing countries! -- Solution to digital divide -- Promotion and enlightenment of Linux * $100 PC -- Orders of millions times several countries -- 512MB Flash ROM + JFFS2 for storage device -- Use of SELinux to enhance security * Threat of zero day attack is serious as there will be a huge amount of machines of an identical configuration - They may be used in the environment where patches cannot be applied easily - To use SELinux, XATTR on JFFS2 must be supported ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 43 Future Works * To reduce memory footprint of POSIX-ACL for JFFS2 -- To implement referring to POSIX-ACL for Ext2/3 -- XATTR in JFFS2 can cache name/value pairs * To develop SELinux commands for busybox -- chcon, setsebool, setenforce etc. * To developemnet policy specific for embedded systems -- Reference Policy assumes use on servers -- Use of attributes is key to reduce policy size -- Security policy for distro not for servers ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 44 Any Question? ---------------------------- = ---------------------------- Copyright (C) 2006, NEC Corporation 45 Appendix -- History of XATTR/JFFS2 Development -- * Revision.1’¡Ê'05/08/23’¡Ë -- Prototype of XATTR/JFFS2; GC not implemented yet * Revision.2’¡Ê'05/09/07’¡Ë --Added GC support for XATTR nodes * Revision.3’¡Ê'05/09/28’¡Ë -- Fixed bug of deadloack in Revision.2 * Revision.4’¡Ê'05/12/28’¡Ë -- Support of Posix-ACL and XATTR initialization in kernel 2.6.14 * Revision.5’¡Ê'06/05/09’¡Ë -- Added EBS (Erase Block Summary) support -- git tree based * Revision.6’¡Ê'05/06/24’¡Ë -- Modified to node deletion by "Delete Marker" ---------------------------- = ----------------------------