Idiomatic solution for tiny systemd "services"?
by Robin Lee Powell
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
9 years, 1 month
selocal script also for RedHat??
by Maurizio Pagani
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
9 years, 2 months
MCS issues
by Tracy Reed
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
9 years, 2 months
rpm_exec and confined type for rpm scriptlets
by Cretu Adrian
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
9 years, 2 months
Core policy upgrades and assigned ports
by Lukas Zapletal
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
9 years, 2 months
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.
9 years, 2 months
Re: Issues with sshd writing to the kernel keyring
by George Karakougioumtzis
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
> ***************************************
9 years, 2 months
