To accomplish this, EVM creates a cryptographic hash (actually an HMAC) or a signature of the extended attributes made with a key loaded at boot time. With EVM, the security sensitive extended attributes are verified against offline tampering. And IMA doesn't prevent this either since the file itself has not been tampered with.Įnter EVM, the Extended Verification Module. Once done, and the guest boots, none of the technologies in place will detect that the extended attribute has been tampered with: SELinux reads the context and treats the file as a regular /etc file. The Linux Integrity Measurement Architecture uses the security.ima extended attribute to store a valid hash of the file in order to detect and prevent offline tampering of files.īut if all this information is stored in extended attributes, then offline tampering of files (and guest images) allows an attacker to circumvent security rules: he can change the label of a file he wants access to when the guest is operational ( /etc/shadow is an obvious example to this, say making it etc_t). SELinux for instance uses the linux extended attribute to store the SELinux security context of a file, directory or other resource. Many of these security technologies use extended attributes for storing information about the state of resources on the system. This interface is called LSM (Linux Security Modules) and is used by technologies such as SELinux, SMACK and IMA as well as many others. The Linux kernel offers a security interface that allows new technologies to properly "hook in" the Linux kernel and extend its capabilities with more security-related features. O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.Using EVM on your system is currently only recommended for development purposes. Get Professional Linux Kernel Architecture now with the O’Reilly learning platform. Such lists fit naturally into the extended attribute model. One use of extended attributes is the implementation of access control lists that extend the UNIX-style permission model: They allow implementation of finer-grained access rights by not only using the concept of the classes user, group, and others, but also by associating an explicit list of users and their allowed operations on the file. This allows a really generic set of attributes without any significant impact on filesystem performance or disk space requirements. Since usually every file will possess only a subset of all possible extended attributes, the attributes are stored outside the regular inode data structure to avoid increasing its size in memory and wasting disk space. Extended attributes (xattrs) are (more or less) arbitrary attributes that can be associated with a file. What the kernel can provide, however, is a framework that allows filesystem-specific extensions. Additional features that go beyond the standard UNIX file model often require an extended set of attributes associated with every filesystem object. It is impossible for the virtual filesystem to provide specific data structures for every feature that can be imagined-fortunately, there's lots of room in our imagination, and developers are not exactly short of new ideas. Many filesystems provide features that extend the standard functionality offered by the VFS layer. Extended Attributes and Access Control Lists
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |