What's the *correct* way to delete a mistake. I just did an semanage
fcontext, and in the wildcard, had *., rather than .*. I seem to have made
selinux stop complaining by deleting the line from
/etc/selinux/targeted/modules/active/file_contexts.local, but I doubt
that's the recommended method....
I run a dovecot instance that looks up users from ldap. Of course, this
is done via SSL/TLS.
As a result, I get a number of denials that dovecot can't read the
Would it be worth adding an optional policy to dovecot.te such as:
PS: What is optional_policy for? Is that just so that if that
interface / type isn't available, it doesn't cause an error in the
William Brown <william(a)firstyear.id.au>
systemd-journald has a facility where it accepts file descriptors from
unprivileged local users and reads the log message from them. This is
done to bypass size restrictions on UNIX domain socket datagram messages.
The code is here in server_process_native_file:
Does this bypass MAC checks because the journald process has different
privileges than the user who opened the file descriptor?
Florian Weimer / Red Hat Product Security Team
CentOS 6.5, selinux-policy-targeted 3.7.19-231.
We have many years of /var/spool/indexes/<user>/... They're currently all
dovecot_t. grep imap /var/log/audit/audit.log | audit2allow tells me "The
source type 'dovecot_t' can write to a 'dir' of the following types: #
dovecot_tmp_t, user_home_t, dovecot_spool_t, mail_home_rw_t,
dovecot_var_log_t, dovecot_var_run_t, mail_spool_t, cluster_conf_t, nfs_t
So, is this trying to tell me that I need to relabel *everything* down
there as something else - dovecot_spool_t, or what?
I have been seeing something that looks like my add on policies aren't being
used after selinux updates in some cases. The modules show up in output
of semodule -l, but I get audit warnings for things allowed by them and some
services don't work as expected. (And the audit2allow output even notes
that they should be allowed by current policy.)
Is there a way I can check to see if semodule -l is telling me what's really
loaded into whatever is doing the enforcing?
I have a policy that was originally written for RHEL 6.2. I’m now trying to upgrade to RHEL 6.5 and I’m having problems with semanage. I can install a fresh RHEL 6.5 system with the targeted policy and everything works fine. I then uninstall the targeted policy and install my policy and I can’t link the linux user and selinux user.
>> semanage user –a -R sysadm_r -R staff_r -r s0-s0:c0.c1023 testuser_u
>> useradd -G wheel testuser
>> semanage login -a -r s0-s0:c0.c1023 -s testuser_u testuser
libsemanage.dbase_llist_query: could not query record value
/usr/sbin/semanage: Could not query user for testuser
I have the RHEL 6.5 source code for libsemanage and the targeted policy but so far I haven't been able to find differences that would affect this problem. Could someone please point me in the right direction as far as what semanage is expecting? What would prevent libsemanage from querying for the user?