transition from init_rc
by Tracy Reed
I think I'm really close to having this policy finished and working, just a
couple things to work out...
When I exercise my app and then run audit2allow and it says:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow myapp_t default_t:dir search;
allow myapp_t default_t:dir read;
allow myapp_t default_t:file execmod;
allow myapp_t myapp_bin_t:file write;
does it mean only the first line is an constraint violation? Or are all of
those constraint violations?
How does one typically deal with constraint violations? By attribute above I
suppose it means a type attribue but how do I know which one to add?
Then I have these:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t default_t:file relabelto;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow initrc_t myapp_api_t:file relabelto;
The init script which starts the service relabels the files when the service
starts. I suspect this is a bad idea and I'm not sure why they are doing it. I
think they may be applying security categories here. We may have to find a
different way to approach that.
But how would I allow this if I wanted to?
Similarly:
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t default_t:file relabelfrom;
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
#Contraint rule:
allow setfiles_t myapp_api_t:file relabelfrom;
etc...
This is all on CentOS 6.5.
Thanks!
--
Tracy Reed
8 years, 4 months
How to label rootfs at the build time?
by Srinivasa Rao Ragolu
Hi All,
I have ported selinux targeted policy (meta-selinux, yocto), to my embedded
platform. But, after first time boot only my rootfs is getting labeled. If
I would like to apply the policy or label my rootfs, what should I do?
Please suggest me the way to enforce policy and label rootfs at the build
time
Thanks,
Srinivas.
8 years, 4 months
newly installed packages mislabeled?
by Chris Murphy
I see restorecon always relabels something, e.g. after doing dnf
upgrade I'll run restorecon and something or other is always reset.
I can't tell if this is a problem or not, but it seems to me the
selinux label for a current package should already be correctly set,
rather than depending on restorecon to reset them. Or is there more
than one valid labeling possible?
For example, the kernel packages are always affected. This is what I
got today after installing kernel 4.2.6-301
http://fpaste.org/295221/
I'm guessing it's the kernel package that's setting the kernel to
system_u:object_r:modules_object_t and then restorecon resets it to
system_u:object_r:boot_t:s0. So is this a nitpick difference, or
should I file a bug against the kernel package so it sets things
correctly from the outset? I don't think we should have to do a
restorecon after every dnf upgrade or install to make sure labeling is
correct.
Similarly, I get:
restorecon reset /sys/fs/cgroup context
system_u:object_r:tmpfs_t:s0->system_u:object_r:cgroup_t:s0
restorecon set context /sys/fs/cgroup->system_u:object_r:cgroup_t:s0
failed:'Read-only file system'
So, whatever is responsible for setting selinux labels on /sys/fs (?)
seems to set that incorrectly, and restorecon can't fix it because
it's an ro filesystem. So is that a bug and if so what should it be
filed against?
Thanks,
--
Chris Murphy
8 years, 4 months
