selinux February 2015

selinux@lists.fedoraproject.org

11 participants
7 discussions

Idiomatic solution for tiny systemd "services"?
by Robin Lee Powell 05 Mar '15

05 Mar '15

Hey all. I have a tiny web service that I'm running with a ruby script in ~/.rvm/ , and I'd like to run it out of systemd (just to keep it running always), but init_t can't read or execute user_home_t. Nor can init_t run runcon. Basically, I can't figure out any way to transition from systemd's init_t to my user's type (staff_t). So what's the idiomatic way to handle that sort of thing? -- http://intelligence.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i dafsku lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u

3 7

selocal script also for RedHat??
by Maurizio Pagani 25 Feb '15

25 Feb '15

Hi men, I'm reading a book about SELinux Administration, and i saw that exist a script for gentoo linux, that is called: selocal Someone do you know if it is available also for RedHat Linux? Thanks in advance, Bye, Maurizio Pagani

2 1

MCS issues
by Tracy Reed 20 Feb '15

20 Feb '15

Once upon a time I had MCS working under RHEL 5 "Getting Started with Multi-Category Security (MCS)" doc. Then the project was shelved for a while and never got deployed. Interest has returned and I am now picking it up again with our current production-deployed OS which is RHEL 6. It seems things have changed significantly. The Getting Started doc doesn't work anymore. Is there any current documentation regarding MCS in 6? I can't seem to find any. I was discussing this on the selinux(a)tycho.nsa.gov list when I was reminded that this list exists and probably has more RHEL/Fedora specific expertise. I would love to point to the previous discussion on selinux(a)tycho.nsa.gov but it seems archives are sadly unavailable or at least Google can't find them. I am trying to sandbox several instances of the same web app on a bunch of machines. Each app runs under a username like p16001 or p16002 etc. We also create a category p16001 and p16002 etc. Each app should only be able to access files with the category by the same name. In RHEL 5 categories were associated with usernames and everything was pretty straightforward. Now I have been told on the other list that categories are associated with user types and that I need to insert a policy module like so: policy_module(mytest, 1.0,0) gen_require(` type user_t; attribute mcsuntrustedproc; ') typeattribute user_t mcsuntrustedproc; I have done this but the MCS is not being enforced. The system is in permissive mode but I expect to see deny messages in the log and there are none. Some of my current (somewhat mangled via experimentation) config: [mcstest:/home/users/tracy.reed]# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles git_shell_u user s0 s0 git_shell_r guest_u user s0 s0 guest_r p16001_u user s0 s0:c1 user_r p16002_u user s0 s0:c2 user_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0-s0:c0.c1023 user_r xguest_u user s0 s0 xguest_r [mcstest:/home/users/tracy.reed]# semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 p16001 p16001_u s0:c1-s0:c1 p16002 appuser_u s0:c1.c499-s0:c2 p16003 appuser_u s0:c1.c499-s0:c3 p16004 unconfined_u s0-s0:c0.c1023,c4 p16005 unconfined_u s0-s0:c0.c1023,c4,c5 p16006 unconfined_u s0-s0:c0.c1023,c6 p16007 unconfined_u s0-s0:c0.c1023,c7 p16008 unconfined_u s0-s0:c0.c1023,c8 p16009 unconfined_u s0-s0:c0.c1023,c9 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 p16001 is associated with p16001_u and has category c1 which all seems fine. # ssh p16001@localhost p16001@localhost's password: Last login: Thu Feb 19 18:06:54 2015 from localhost -bash-4.1$ cd /glide/ backup/ include/ lib64/ share/ bin/ java/ logs/ snc-provision/ chroot/ java-1.6.0_45.i586/ nodes/ temp/ cid/ lib/ runbooktmp/ -bash-4.1$ cd /glide/ backup/ include/ lib64/ share/ bin/ java/ logs/ snc-provision/ chroot/ java-1.6.0_45.i586/ nodes/ temp/ cid/ lib/ runbooktmp/ (reverse-i-search)`': ^C -bash-4.1$ cd /glide/nodes/ -bash-4.1$ ls p16001 p16002 p16003 -bash-4.1$ ls -laZ drwxr-xr-x. root root system_u:object_r:default_t:s0 . drwxrwxr-x. root root system_u:object_r:default_t:s0 .. drwxr-xr-x. p16001 p16001 user_u:object_r:default_t:s0:c1 p16001 drwxr-xr-x. p16002 p16002 user_u:object_r:default_t:s0:c2 p16002 drwxr-xr-x. p16003 p16003 user_u:object_r:default_t:s0:c3 p16003 -bash-4.1$ cd p16001/ -bash-4.1$ ls -laZ drwxr-xr-x. p16001 p16001 user_u:object_r:default_t:s0:c1 . drwxr-xr-x. root root system_u:object_r:default_t:s0 .. -rw-r--r--. p16001 p16001 user_u:object_r:default_t:s0:c1 testfile -bash-4.1$ cat testfile I am 16001 -bash-4.1$ -bash-4.1$ pwd /glide/nodes/p16001 -bash-4.1$ cd ../p16002/ -bash-4.1$ ls -laZ drwxr-xr-x. p16002 p16002 user_u:object_r:default_t:s0:c2 . drwxr-xr-x. root root system_u:object_r:default_t:s0 .. -rw-r--r--. p16002 p16002 user_u:object_r:default_t:s0:c2 testfile -bash-4.1$ cat testfile I am 16002 -bash-4.1$ id uid=16001(p16001) gid=16001(p16001) groups=16001(p16001) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Hmm...now for some reason my p16001 user is in unconfined. So I now have two problems: Why is this p16001 user not confined? The output of semanage login -l (maps linux users to selinux users) shows linux user p16001 associated with selinux user p16001_u: p16001 p16001_u s0:c1-s0:c1 And the output of semange user -l shows: p16001_u user s0 s0:c1 user_r So why would p16001 be unconfined and MCS not enforcing? Any tips that can be provided are greatly appreciated! -- Tracy Reed

1 0

rpm_exec and confined type for rpm scriptlets
by Cretu Adrian 18 Feb '15

18 Feb '15

Hi, Is there a way I can permit a user confined by selinux to run rpm but the scriptlets to be executed in user's domain type instead of rpm_script_t ? I have a use case where I need to permit some users to install rpms but in same time I need to confine them so would not interfere with files that define network interfaces/kernel and so on. Thanks

3 2

Core policy upgrades and assigned ports
by Lukas Zapletal 05 Feb '15

05 Feb '15

Hello, for our project policy, we define several new port types which were not yet introduced in RHEL6 (docker_port_t) and Fedora (elasticsearch_port_t). We have a port type declaration in our policy and port assignment in our package deployment script/scriplet. I wonder what happens when you introduce a port mentioned above in the core policy. My experiences so far is that policy load will fail because ports types cannot be redefined and the same for assignments. I was thinking if there is a generic workaround for this. I was thinking if there is a port type naming convention that you guys would expect in our upgrade scripts being able to undefine the port number prior upgrade. Something like: custom_2375_port_t in case of docker. Such ports with some expected prefix could be easily determined and all removed prior the upgrade. After that, we'd need to upgrade our policy to create appropriate rules of course, but this is much cleaner than having a conflict. Is there such a naming convention? If not, is this the way this could be solved upstream and downstream? Thanks -- Later, Lukas #lzap Zapletal

1 0

Creating home directories with wrong context
by Jayson Hurst 05 Feb '15

05 Feb '15

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.

2 6

Re: Issues with sshd writing to the kernel keyring
by George Karakougioumtzis 03 Feb '15

03 Feb '15

Its not an actual answer but rather an idea based upon Dan's mail. What if pam_keyring would be patched to supply the correct label? Just food for thought On 02/01/2015 02:00 PM, selinux-request(a)lists.fedoraproject.org wrote: > Send selinux mailing list submissions to > selinux(a)lists.fedoraproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://admin.fedoraproject.org/mailman/listinfo/selinux > or, via email, send a message with subject or body 'help' to > selinux-request(a)lists.fedoraproject.org > > You can reach the person managing the list at > selinux-owner(a)lists.fedoraproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of selinux digest..." > > > Today's Topics: > > 1. Re: Issues with sshd writing to the kernel keyring > (Jason L Tibbitts III) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 31 Jan 2015 15:45:31 -0600 > From: Jason L Tibbitts III <tibbs(a)math.uh.edu> > To: Daniel J Walsh <dwalsh(a)redhat.com> > Cc: selinux(a)lists.fedoraproject.org > Subject: Re: Issues with sshd writing to the kernel keyring > Message-ID: <ufay4oi1v5w.fsf(a)epithumia.math.uh.edu> > Content-Type: text/plain > >>>>>> "DJW" == Daniel J Walsh <dwalsh(a)redhat.com> writes: > DJW> The labelling of the kernel keyring has never been handled > DJW> correctly. The keyring gets created with a label based on the > DJW> creating object then all sorts of other confined domains end up > DJW> using the same keyring. > > Ah, that makes a lot of sense. I have managed to get around it by > restarting things, but knowing that whatever creates the keyring > specifies the label does explain what I'm seeing, including the rare > startup race. > > Do you know if it's possible to somehow look at the kernel keyring and > see the labeling of things? /proc/keys doesn't tell me. > > DJW> I would just allow the access. You should open a bug with > DJW> selinux-policy to allow sshd_t to write to the gssd_t keyring. > > I reopened the existing bug, which was on F20 (and seemingly solved > there) but which didn't get carried over to F21 somehow. That is > https://bugzilla.redhat.com/show_bug.cgi?id=1063827 > > I can open a new ticket if that would be better. > > - J< > > > ------------------------------ > > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux > > End of selinux Digest, Vol 132, Issue 1 > ***************************************

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux February 2015