NFS and selinux context question
by Ed Greshko
Hi,
The configuration is a Fedora NFS server holding the home directories of Fedora clients. So, all Fedora.
Example: A user on the client creates a ~/.cert directory. Looking at the directory from the server side we see.
[djensen@f35ser ~]$ ls -Zd .cert
system_u:object_r:home_cert_t:s0 .cert
On the client side the user sees
[djensen@f35k ~]$ ls -Zd .cert
system_u:object_r:nfs_t:s0 .cert
Is there a way the client side can show the actual selinux context that is being enforced on
the server side?
--
Nothing to see here
2 years, 2 months
Custom unix local socket type
by MK
Hello!
I created a small server app module that I included a custom socket type in:
type plazerine_socket_t;
typeattribute plazerine_socket_t file_type, non_auth_file_type, non_security_file_type;
This is for a unix local stream socket, for which there is a file context rule:
semanage fcontext -a -t plazerine_socket_t /usr/local/etc/plazerine/msgin
The server executable is labeled 'plazerine_exec_t', and the process derived from it
transistions to 'plazerine_t'. However, when it creates and opens the socket, the
file always ends up typed `plazerine_exec_t` (requiring various socket oriented
permissions on that type).
There's no AVC denial to interpret (which is how I've mostly found my way around), and
this isn't deal breaking for me -- in a sense having a separate type for the socket may
be sort of redundant. OTOH, it would provide some more fined grained depending on
how complex the system using the exec type is.
Is there a right way to do this? I notice via `seinfo -t` there is a handful of what seem
by name to be custom socket types, and they are defined typeattribute wise the
same way I've done it above.
This is on a policy v.33 fedora system, targeted, enforcing.
- MK
2 years, 2 months
Re: "semanage boolean -l" shows separate strings
by Petr Lautrbach
Samuel Fusato <samuelfusato(a)gmail.com> writes:
>> Hope you are well. When you have time, can you kindly let me know why the
>> command "semanage boolean -l" shows "homedirs" and "home dirs" on the
>> Description of the booleans? Examples:
>>
>> [root@workstation ~]# semanage boolean -l | grep httpd_enable_homedirs
>> httpd_enable_homedirs (off , off) Allow httpd to enable
>> *homedirs*
>>
>> [root@workstation ~]# semanage boolean -l | grep use_nfs_home_dirs
>> use_nfs_home_dirs (off , off) Allow use to nfs *home dirs*
>>
>> Why is there not a sort of standardization there?
>>
In this case descriptions are generated from boolean names. The
algorithm is simple - the boolean name is split using '_', first world
is usually subject then perm then object. 'Allow' is at adaed to the
beginning and 'to' is added between subject and perm. It generally
works reasonably well:
httpd_enable_homedirs -> Allow httpd to enable homedirs
but
use_nfs_home_dirs -> Allow use to nfs home dirs
If you want better descriptions, you can install `selinux-policy-devel`:
# dnf install selinux-policy-devel
# semanage boolean -l | grep httpd_enable_homedirs
httpd_enable_homedirs (off , off) Allow httpd to read home directories
As for the boolean names - httpd_enable_homedirs vs use_nfs_home_dirs -
I don't know why they are inconsistent. It might be related to the fact
that `homedirs` could be a feature for httpd, but it home dirs when we
talk about nfs. I don't know.
Petr
2 years, 3 months
Failed to resolve typeattributeset
by lejeczek
Hi guys.
I'm trying to remove an old custom module but I fail:
-> $ semodule -X 300 -r charonsystemd-mine
libsemanage.semanage_direct_remove_key: Removing last
charonsystemd-pawel module (no other charonsystemd-pawel
module exists at another priority).
Failed to resolve typeattributeset statement at
/var/lib/selinux/targeted/tmp/modules/400/me-libvirt/cil:5
semodule: Failed!
Care to share your thoughts?
many thanks, L
2 years, 3 months
