semanage error when upgrading to RHEL 6.5
by Andy Ruch
Hello,
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?
Thanks,
Andy
10 years, 2 months
Adoption to Ref-Policy sysadm_t
by Philipp
Hi all,
I am trying to adopt the reference policy in a way that the sysadm_t domain
isn't able to open SELinux configuration files or run any related binaries
like semange. My approach was to edit the sysadm.te file and uncomment the
related lines in there. Thus far, I haven't found the right entries:
I looked up with sesearch for the following lines:
sesearch --all -s sysadm_t -t selinux_config_t |
Output:
allow sysadm_t non_security_file_type : file { ioctl read write create
getattr setattr lock relabelfrom relabelto append unlink link rename open }
;
allow sysadm_t non_security_file_type : dir { ioctl read write create
getattr setattr lock relabelfrom relabelto unlink link rename add_name
remove_name reparent search rmdir open } ;
allow sysadm_t non_security_file_type : lnk_file { ioctl read write
create getattr setattr lock relabelfrom relabelto append unlink link rename
} ;
allow sysadm_t non_security_file_type : chr_file { getattr relabelfrom
relabelto } ;
allow sysadm_t non_security_file_type : blk_file { getattr relabelfrom
relabelto } ;
allow sysadm_t non_security_file_type : sock_file { getattr relabelfrom
relabelto } ;
allow sysadm_t non_security_file_type : fifo_file { getattr relabelfrom
relabelto } ;
allow sysadm_t file_type : filesystem getattr ;
allow sysadm_usertype file_type : filesystem getattr ;
allow sysadm_t selinux_config_t : dir { getattr search open } ;
allow sysadm_usertype selinux_config_t : file { ioctl read getattr lock
open } ;
allow sysadm_usertype selinux_config_t : dir { ioctl read getattr lock
search open } ;
allow sysadm_usertype selinux_config_t : lnk_file { read getattr } ;
I thought that there must be some entries corresponding the last few lines,
but as already mentioned I haven't found any in the
rpmbuild/SOURCES/serefpolicy-3.7.19/policy/modules/roles/sysadm* files.
What I am doing wrong or where do I have to change something?
Thank you in advance!
10 years, 2 months
Creating a second /home directory root (/local-home) with apropriate labels?
by Jonathan Abbey
Hi, folks.
In our laboratory, we have an NIS / automounted NFS environment in
which every NIS user gets placed under an automounted /home.
For one of our users on Fedora 20, I'm attempting to give him an
auxiliary local account whose home directory is mounted under
/local-home/, and I'm trying to figure out how to tell SELinux that
everything under /local-home should be treated analogously to how it
would be treated under /home.
Unfortunately, I've not yet figured out the magic incantation to do
this.
I found /etc/selinux/targeted/contexts/files/file_contexts.homedirs,
and I was able to copy that and sed it with s/\/home/\/local-home/,
after which I could then do a setfiles on my copy to set the
appropriate labels on his existing /local-home/username directory, but
this is obviously just temporarily curing the symptom rather than
fixing the policy appropriately for local accounts going forward.
I expect that there are policy editing tools that I could use to fix
the policy up, for all pre-defined file contexts, but I don't know how
to do that efficiently.
Nor do I know how to arrange things so that third party policy modules
that might be installed later (like for Google's Chrome RPM?) would
inherit the new file_context rules for /local-home appropriately.
Any hints would be extremely helpful.
Thanks,
Jon
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey(a)arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
10 years, 2 months
Review of yubikey selinux policy
by William
Hi,
The current policy for yubikeys only takes into account the otp
functions. In addition, the pam module supports a local challenge
response mode.
I have attached a patch to allow chap to work for yubikeys with selinux
enabled. To note is that I have added a auth_home_rw_t type, as the pam
module reads from ~/.yubico/challenge-<tokenid> and then rewrites it
with a new challenge after the attempt.
I would like to especially ask that the section for the chap tunable
policy be reviewed. In my testing, it seemed that login_pgm wasn't
sufficient, as staff_sudo_t didn't seem to be covered by this which is
why I have added the sudodomain components. I would like to know if
there is a better way to resolve this.
Sincerely,
--
William Brown <william(a)firstyear.id.au>
10 years, 2 months
postfix sasl denials
by Natxo Asenjo
hi,
when trying to relay e-mail using SASL authentication on a ipa centos
domain I get this this on audit.log:
type=AVC msg=audit(1395749719.107:875): avc: denied { unlink } for
pid=4229 comm="smtpd" name="smtp_89" dev=dm-0 ino=265669
scontext=unconfined_u:system_r:postfix_smtpd_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1395749719.109:876): avc: denied { getattr } for
pid=4229 comm="smtpd" path="/var/tmp/smtp_89" dev=dm-0 ino=265669
scontext=unconfined_u:system_r:postfix_smtpd_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1395749719.109:877): avc: denied { unlink } for
pid=4229 comm="smtpd" name="smtp_89" dev=dm-0 ino=265669
scontext=unconfined_u:system_r:postfix_smtpd_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1395749719.110:878): avc: denied { getattr } for
pid=4229 comm="smtpd" path="/var/tmp/smtp_89" dev=dm-0 ino=265669
scontext=unconfined_u:system_r:postfix_smtpd_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
de local user postfix is indeed id 89. In /var/tmp/smtp_89 I have the
kerberos ticket that the relay server is using
(smtp/testsmtprelay.sub.domain.tld(a)SUB.DOMAIN.TLD)
$ sudo ls -Z /var/tmp/
-rw-------. root root system_u:object_r:krb5_host_rcache_t:s0 host_0
-rw-------. postfix postfix unconfined_u:object_r:user_tmp_t:s0 smtp_89
if i set selinux in permissive mode, I may relay using sasl, otherwise it
gets blocked.
Any clues on how to fix this to keep selinux enabled?
TIA,
--
Groeten,
natxo
10 years, 2 months
Firefox
by hibhib＠hushmail.com
I have a default Fedora 20 system. I have made no SELinux policy
changes from the default.
How do I enable SELinux protection for Firefox? Are there some simple
steps I can take? I see that there is a "mozilla" policy but firefox
always runs in unconfined domain.
Thanks!
10 years, 2 months
file_context.local and relative paths
by Shade, Matt (US)
Hi folks,
This is more of a curiosity question, and I haven't found any answer yet.
If I receive an AVC and sealert tells me to
chcon -R -t something_log_t './logs' with a subsequent semanage
then it goes into file_context.local exactly how I entered it.
Cool, I would expect that. But it got me thinking about setfiles/restorecon, and what if I have another directory named logs that requires relabelling?
For example, let's say that today I find incorrect labelling on /somedir/logs and so I fix it with chcon/semanage.
Then next year, I add a new application and it has /anotherdir/logs that is incorrectly labelled. SELinux is going to complain about ./logs again, so I may just cd into /anotherdir and do my chcon/semanage with another_log_t label to this ./logs.
That would change the old label, I would think (unless I'm relabelling to the same label), and so now restorecon ./logs will apply the new label to whichever directory I would have to fix.
Also, say I actually think about that beforehand and decide to use a full path in my restorecon command -- restorecon -v /somedir/logs -- will it be smart enough to know which logs entry in file_context.local I mean, or do I have to remember that I used a relative path when I created the entry and use that in the restorecon command?
So I guess ultimately the question is, wouldn't it be better for semanage to require full paths?
Matt Shade
This message and any attachment(s) are intended only for the use of the person or entity to which it is addressed and may contain confidential and/or proprietary information. Any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this message and any attachment(s) by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and delete this message, including any attachments. Sender accepts no liability for any damages caused by any virus transmitted by this e-mail.
10 years, 3 months
setsebool -P cron_userdomain_transition on not permanent?
by Bruno Wolff III
I have been setting cron_userdomain_transition on because otherwise cron
doesn't work. However despite using the -P option I have occasionally
had to go back and set the boolean again.
Is there some changes going on in policy updates that would affect this?
How do I check that the change is stored in the policy, and not just
in effect until the next reboot?
10 years, 3 months
