I am trying to run SELinux chcon command on a UBIFS root filesystem and I get chcon: failed to change context of '/' to 'system_u:object_r:root_t': Operation not supported. I understand SELinux needs filesystem support for extended attributes. For Linux kernel <3.4, CONFIG_UBIFS_FS=y will enable extended attributes for UBIFS by default.
I read from here that xattr should automatically be enabled without additional mount options.
Extended attributes
UBIFS supports extended attributes if the corresponding configuration option is enabled (no additional mount options are required). It supports the user, trusted, and security name-spaces. However, access control lists (ACL) support is not implemented.
Note, currently mkfs.ubifs ignores extended attributes and does not write them to the target file-system image.
I am building the image using Yocto, and added xattr to DISTRO_FEATURES as well. What am I missing here?
Related
I am running into a problem with labeling. In order to lock down access to a file /etc/avahi/avahi-daemon.conf I decided to label it as a part of the avahi_t domain.
I am working on an embedded system. When I boot up the system from a version update, the file system is relabeled with the .autorelabel flag set.
Unfortunately the file /etc/avahi/avahi-daemon.conf remains in the unlabeled_t type. Due to the label being wrong, it is unable to read the file and avahi fails to initialize properly with an avc read denied on an unlabeled_t file. I want to have the label correctly set and not modify policy to read an unlabeled file. I also want it to be protected so the configuration can not be modified.
I have properly labeled it in the .fc file with the following:
/etc/avahi/avahi-daemon.conf -- gen_context(system_u:object_r:avahi_t,s0)
When I try a restorecon on the file system it attempts to relabel the file but is blocked by SELinux with a relabelto avc violation. Similarly changing it with chcon -t fails to change it. I do not wish to open relabelto up on an embedded system as it can then be relabeled and take down the avahi initialization. If I take out the SD card, and relabel the file on a different system. And place it back into the target system it is properly labeled. And avahi operates correctly. So I am certain that the labeling is causing the problem.
In looking in the reference policy an init_daemon_domain(avahi_t,avahi_exec_t) is being performed.
In looking at the documentation for init_daemon_domain() it states the following:
"The types will be made usable as a domain and file, making calls to domain_type() and files_type() redundant."
This is unusual in that if I add files_type(avahi_t) to the .te file, it properly labels after version update.
I am really wanting to know more information about this, and unfortunately my searches on the internet have been less than fruitful in this regard.
Is the documentation for SELinux wrong? Am I missing something about init_daemon_domain() in that it only works with processes and not files?
Or is the files_type(avahi_t) truly needed?
I know this comes off as a trivial issue since there is a path to where it is working. However I am hoping to get an explanation as to why files_type(avahi_t) is necessary?
Thanks
Given is a container that has pid=host (so it is in the initial PID namespace and has a full view on all processes). This container (rather, its process) additionally has the capabilities CAP_SYS_ADMIN and CAP_SYS_CHROOT, so it can change mount namespaces using setns(2).
Is it possible using AppArmor to block this container from accessing arbitrary files in the host (the initial mount namespace), except for some files, such as /var/run/foo?
How does AppArmor evaluate filesystem path names with respect to mount namespaces? Does it "ignore" mount namespaces and just take the specified path, or does it translate a path, for instance when dealing with bind-mounted subtrees, etc?
An ingrained restriction of AppArmor's architecture is that in case of filesystem resources (files, directories) it mediates access using the access path. While AppArmor uses labeling, as does SELinux, AppArmor derives only implicit filesystem resource labels from the access path. In contrast, SELinux uses explicit labels which are stored in the extended attributes of files on filesystems supporting POSIX extended attributes.
Now, the access path always is the path as seen in the caller's current mount namespace. Optionally, AppArmor can take chroot into account. So the answer to the second question item is: AppArmor "ignores" mount namespaces and just takes the (access) path. It does not translate the bind mounts, as far as I understand (there's nowhere any indication to be seen it would do).
As for the first question item: in general "no", due to AppArmor mediating access path (labels), not file resource labels. A limited access restriction is possible when accepting that there won't be any access path differentiation between what's inside a container and what's in the host outside the container (same for what's inside other containers). This is basically what Docker's default container AppArmor profile does: restricting all access to a few highly sensitive /proc/ entries and restricting to read-only access for many other /proc/ entries.
But blocking access to certain host file access paths always comes with the danger of blocking the same access path for a perfectly valid use inside a container (different mount namespace), so this requires great care, lots of research and testing, as well as the constant danger of things breaking in the next update of a container. AppArmor seems to not be designed for such usecases.
Docker's default container AppArmor profile contains a single "file" clause, without any additional information:
file,
What does this really mean, does this clause grant full access to any file? I've checked with AppArmor's apparmor.d(5) man page, but it does not mention this case explicitly, contrary to, say:
# Allow all PTrace access
ptrace,
Months later I finally stumbled upon an explanation, not from the AppArmor project itself, but from OpenSUSE, in their "Security and Hardening Guide", chapter "Profile Components and Syntax", heading "30.7.70 Optional allow and file Rules":
The following rule grants access to all files:
file,
I have pcspkr in blacklisted in /etc/modprobe.d/pcspkr.conf. However, I can manually load the module using modprobe.
I'm guessing, some other component will be able to do the same via module alias mechanism. Is there a way to permanently block automatic loading of a specific kernel module?
My use case is that I want to experiment with an alternative driver than the one provided in-tree. For this, I do not want the system's default driver showing up. I do not want to delete the golden driver provided by the kernel and screw up either.
What options do I have ?
I have modified the default "nvme" device driver to suit my project and I am trying to automatically load the modified nvme driver (mnvme) at boot time but I am not successful.
I have edited /lib/modules/{kernel-version}/modules.alias file to include "mnvme" instead of "nvme" but the default "nvme" keeps getting loaded.
I also see mnvme: module verification failed: signature and/or required key missing - tainting kernel on kernel messages.
Note: I am able to manually remove "nvme" and load "mnvme" using rmmod and insmod commands respectively. I would prefer to do it automatically at boot time
Thanks,
Bala.
To automatically load your module:
Copy all .ko files related to your module into respective location under /lib/modules/{kernel-version}/kernel/, e.g. under /lib/modules/4.1.19-v7+/kernel/drivers/nvme/ for nvme driver.
Run depmod -a. That should update information required by modprobe which is used to automatically load the modified module. A useful resource for how kernel modules get loaded is section 1.2 'How Do Modules Get Into The Kernel?' of this guide http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf.
If you've modified any headers that you need in user space then make sure to update relevant header file under /usr/include.
To avoid taint message, the commit the changes you've made, e.g. git commit -sam "....".