Creating home directories with wrong context
by Jayson Hurst
I am trying to figure out why a policy that was written on RHEL 6.0 doesn't work the same on RHEL 6.5.
I have a policy whose domain is vasd_t
I am using the userdomain.if interface call which is supposed to give the domain access to create directories in the home dir root with the user home directory type.
userdom_home_filetrans_user_home_dir(vasd_t)
Which calls:
files_home_filetrans($1, user_home_dir_t, dir)
Which calls:
filetrans_pattern($1, home_root_t, $2, $3)
Which is defined as:
allow $1 $2:dir rw_dir_perms;
type_transition $1 $2:$4 $3;
I would expect this to allow me to create a new directory in /home which is of type home_root_t, but what I am seeing is that the new homedir is being created with the type of home_root_t and not user_home_dir_t as expected.
I have also tried not calling the interface methods and defining it by hand as:
allow vasd_t home_root_t:dir rw_dir_perms;
type_transition vasd_t home_root_t:dir user_home_dir_t;
I have also tried calling userdom_create_user_home_dirs(vasd_t)
sesearch shows:
$ sesearch -AC | grep 'allow vasd_t' | grep ': dir' | grep home_root_t
allow vasd_t home_root_t : dir { ioctl read write getattr lock add_name remove_name search open } ;
The way the daemon works that is associated to the vasd_t domain is that it calls a script that does the actual creation of the homedir. I believe the problem lies in this fact that perhaps the script isn't being invoked in a way to give it proper creation rights.
Like I said this use to work in RHEL 6.0 but now I cannot seem to get it to work in 6.5. Any help would be appreciated. I don't know what I am missing here.
8 years, 7 months
Issues with sshd writing to the kernel keyring
by Jason L Tibbitts III
I'm trying to get all of this fancy kerberized NFS stuff working and I'm
having a problem where credential forwarding via ssh doesn't work due to
selinux. Running fully update Fedora 21
(selinux-policy-targeted-3.13.1-103.fc21.noarch,
kernel-3.18.3-201.fc21.x86_64) I get the following AVCs:
time->Thu Jan 29 20:25:18 2015
type=AVC msg=audit(1422584718.991:278): avc: denied { read } for
pid=1272 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:gssd_t:s0 tclass=key permissive=0
----
time->Thu Jan 29 20:25:18 2015
type=AVC msg=audit(1422584718.991:279): avc: denied { write } for
pid=1272 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:gssd_t:s0 tclass=key permissive=0
And sshd logs a failure:
Jan 29 20:30:00 ld82.e.math.uh.edu sshd[1464]: debug1: temporarily_use_uid: 7225/7225 (e=0/0)
Jan 29 20:30:00 ld82.e.math.uh.edu sshd[1464]: debug1: ssh_krb5_cc_gen: Setting ccname to KEYRING:persistent:7225
Jan 29 20:30:00 ld82.e.math.uh.edu sshd[1464]: krb5_cc_initialize(): Permission denied
Jan 29 20:30:00 ld82.e.math.uh.edu sshd[1464]: debug1: restore_uid: 0/0
I don't know what causes this; sometimes it just starts working randomly
(and the AVCs go away). I don't know if this is a bug or if I'm doing
something wrong. If I disable selinux (setenforce 0) it immediately
starts working.
- J<
8 years, 7 months
Re: audit2allow help to allow, but how to disallow
by Daniel J Walsh
On 01/21/2015 12:28 AM, Bhuvan Gupta wrote:
> I am working with selinux sandbox
> "http://danwalsh.livejournal.com/28545.html".
>
> Blog clearing mentions that the sandbox "Can not Open or Create any
> files on the system " except the the shared libraries.
>
> But current sandbox allow to read dir stuff which i think should not
> be allowed:
> currently i can successfully ran: /
> "sandbox ls /usr"/
> ls -Z for my /usr is:
> /drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr/
>
Right this is system objects. You are allowed to read/execute most
content under /usr, since sandbox needs to execute programs.
> Now i used sesearch based policy analysis tool to find the allow rules
> and i have listed few which i can understand and think should not be
> there:
> [1] /allow sandbox_domain default_t : file { ioctl read write getattr
> lock append } ; / # sandbox_t is allow to read write to file having
> type as default_t, but it doesnt allow to open it..so whats the
> significance of {read write}
This is for leaking a file descriptor into the container. cat /foo/bar
| sandbox app > /tmp/output
We want to allow a user to open a file descriptor to any object on the
machine and then leak the file descriptor into the sandboxed app. The
sandboxed app is not allowed to Open any files on the system except
content with base labels, like usr_t, etc_t, bin_t, lib_t. And these
labels it is not allowed to write.
> [2] /allow domain usr_t : dir { ioctl read getattr lock search open } /
>
> Added my system details and also attached the completed allowed list .
>
> I have started with selinux about 1 week back so there might be
> problem with my thinking model.
> /*Does the above stuff make sense from logical point of view and
> should fixed ?*/
> Initially i thought that i will just disallow what i dont want...but
> know i have realised that selinux is denial by default model and we
> can only allow stuff.
>
Correct. If you want to write a more confined SELinux Type, you can,
but you have to start from scratch. And then you allow what you want.
There is an effort to build
a new language called CIL, which would allow you to take an existing
type and create a new type based on that type and remove access. But we
currently do not use this language
> >>yum list installed | grep selinux
> libselinux.x86_64 2.2.2-6.el7
> libselinux-python.x86_64 2.2.2-6.el7
> libselinux-utils.x86_64 2.2.2-6.el7
> selinux-policy.noarch 3.12.1-153.el7_0.13
> selinux-policy-devel.noarch 3.12.1-153.el7_0.13
> selinux-policy-sandbox.noarch 3.12.1-153.el7_0.13
> selinux-policy-targeted.noarch 3.12.1-153.el7_0.13
>
> >> yum list installed | grep sandbox
> selinux-policy-sandbox.noarch 3.12.1-153.el7_0.13
>
> Thanks
> Bhuvan
>
> On Tue, Jan 20, 2015 at 2:36 AM, Daniel J Walsh <dwalsh(a)redhat.com
> <mailto:dwalsh@redhat.com>> wrote:
>
> What do you want to Disallow?
>
>
> On 01/18/2015 06:34 AM, Bhuvan Gupta wrote:
>> Hello,
>>
>> "Audit2allow" can add rule to allow some operation.
>> But let say we want to disallow some operation which is allowed
>> by some policy module. let say open operation on some files.
>>
>> Is there a easy way to achieve that ?
>>
>> Or i do have to:
>> [1] get the policy source.
>> [2] edit it accordingly
>> [3] build and reinstall the policy.
>>
>>
>> Thanks
>> Bhuvan
>>
>>
>>
>>
>> --
>> selinux mailing list
>> selinux(a)lists.fedoraproject.org <mailto:selinux@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
8 years, 7 months
audit2allow help to allow, but how to disallow
by Bhuvan Gupta
Hello,
"Audit2allow" can add rule to allow some operation.
But let say we want to disallow some operation which is allowed by some
policy module. let say open operation on some files.
Is there a easy way to achieve that ?
Or i do have to:
[1] get the policy source.
[2] edit it accordingly
[3] build and reinstall the policy.
Thanks
Bhuvan
8 years, 8 months
place for Postfix keytab files to make selinux happy
by Stephen Ingram
I'm using Fedora 20 and CentOS 7 and have tried several places to place
keytab files for Postfix. Each time I'm getting a denied message:
type=AVC msg=audit(1419366895.530:491753): avc: denied { search } for
pid=28412 comm="lmtp" name="postfix" dev="xvda1" ino=1223493
scontext=system_u:system_r:postfix_smtp_t:s0
tcontext=system_u:object_r:postfix_data_t:s0 tclass=dir
type=SYSCALL msg=audit(1419366895.530:491753): arch=c000003e syscall=4
success=no exit=-13 a0=7f347b8377f0 a1=7fffa6f23670 a2=7fffa6f23670
a3=7fffa6f23540 items=0 ppid=28406 pid=28412 auid=4294967295 uid=89 gid=89
euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 tty=(none) ses=4294967295
comm="lmtp" exe="/usr/libexec/postfix/lmtp"
subj=system_u:system_r:postfix_smtp_t:s0 key=(null)
I see on the postfix_selinux man page that there is a postfix_keytab_t
type, however, even if I use this, postfix is not able to read the
credential file. Has anyone gotten this to work?
Steve
8 years, 8 months
Fetchmail as root
by glandvador
Hi,
I am using fetchmail as root to collect emails.
fetchmail is launched by systemd through a fetchmail.service (see below)
The /etc/fetchmail.conf file contains a list as
poll mail.server.com with
interval 1
protocol imap port 993
username "user" password "pass" is name(a)domain.com
ssl
keep
;
As a result I have the following selinux messages (sealert below):
time->Sun Jan 11 13:07:33 2015
type=AVC msg=audit(1420978053.531:434): avc: denied { write } for pid=820 comm="fetchmail" scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0 tclass=key permissive=1
----
time->Sun Jan 11 13:07:33 2015
type=AVC msg=audit(1420978053.531:435): avc: denied { read } for pid=820 comm="fetchmail" scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0 tclass=key permissive=1
----
time->Sun Jan 11 13:07:33 2015
type=AVC msg=audit(1420978053.531:436): avc: denied { view } for pid=820 comm="fetchmail" scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0 tclass=key permissive=1
What can I do to have a more useful information to solve this problem? Actually this is the last AVC appearing in my logs and I want to solve it before changing the permissive mode to enforcing.
--------------------------------------------------------------------------------
[Unit]
Description=Mail Retrieval Agent
After=network.target
[Service]
PermissionsStartOnly=true
ExecStart=/usr/bin/fetchmail --daemon 600 -f /etc/fetchmail.conf --syslog --nobounce
ExecStop=/usr/bin/fetchmail --quit
Restart=always
Type=simple
[Install]
WantedBy=multi-user.target
--------------------------------------------------------------------------------
SELinux is preventing fetchmail from read access on the key Unknown.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that fetchmail should be allowed read access on the Unknown key by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep fetchmail /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:fetchmail_t:s0
Target Context system_u:system_r:fetchmail_t:s0
Target Objects Unknown [ key ]
Source fetchmail
Source Path fetchmail
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-103.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name hostname.domain.com
Platform Linux hostname.domain.com 3.17.8-300.fc21.x86_64 #1
SMP Thu Jan 8 23:32:49 UTC 2015 x86_64 x86_64
Alert Count 238
First Seen 2015-01-06 09:08:52 CET
Last Seen 2015-01-11 13:07:33 CET
Local ID 158da9a2-8097-4c28-a055-98bee6b61498
Raw Audit Messages
type=AVC msg=audit(1420978053.531:435): avc: denied { read } for pid=820 comm="fetchmail" scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0 tclass=key permissive=1
Hash: fetchmail,fetchmail_t,fetchmail_t,key,read
8 years, 8 months
fcontext equivalence listing
by Robert Nichols
Is there a way to get a list of the current fcontext "equivalence"
customizations? Those don't appear in "semanage -o" output, though
"semanage fcontext -D" does dutifully delete them.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8 years, 8 months
Strange restriction for setfiles_t
by Robert Nichols
I find it odd that a setfiles_t process is allowed to read user_home_t
files but not admin_home_t. So, to use "semanage -i ..." I need to
store the file in a less protected location?
(Or use "cat xxx | semanage -i", of course.)
type=AVC msg=audit(1420507367.059:518): avc: denied { read } for pid=13112
comm="setfiles" path="/root/SElinux/contexts" dev=dm-0 ino=560291
scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
selinux-policy-3.7.19-260.el6_6.1.noarch
selinux-policy-targeted-3.7.19-260.el6_6.1.noarch
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8 years, 8 months
system-config-linux.py GUI inserts corrupt file labeling rule
by Robert Nichols
Want to have fun? Run the system-config-linux GUI, go to "File Labeling"
and add a file context, let's say "var_t" for /tmp/junk regular file.
Hint: It would be wise to save all your local customizations before
trying that.
What you get is a corrupt rule where the File Type is shown as
[''.'--','-d','-c','-b','-s','-l','-p']
Now you are stuck. Because of the corrupt file type you can't delete
this rule. You can no longer save your local customizations because
"semanage -o" barfs on the corrupt type. Your only choice is to run
"semanage fcontext -D" to delete _all_ your customized contexts and
load them in again (_without_ using the GUI).
It doesn't matter what file type you selected. All are bad.
Doesn't anybody test this stuff?
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8 years, 8 months
Looking for a SELinux Demo
by MJang
Hi,
Perhaps my googles are just failing me.
I'm looking for a demo of a security breach when SELinux is disabled --
and how that security breach is stopped with SELinux is enabled.
Alternatively, perhaps my imagination is failing me -- is there some
such demo that I could put together?
Thanks,
Mike
8 years, 8 months
