Determine whether Cron can execute jobs on behalf of the user with login user SELinux permissions

Cron would run jobs on behalf of users in a "cronjob" domain. This domain is reasonable restricted compared to the domain in which most users operate.

Fedora changed this behaviour to allow Cron to execute these jobs in the default login user domain of the user that owns the job.

Recently i added a boolean to Reference policy that enables one to tune the policy to allow Cron to run user cronjobs in the default login user domain conditionaly.

By default Cron will still execute the jobs in the Cron job domain but if you toggle the cron_userdomain_transition boolean to true then Cron will run the jobs in the default login user domain of the user owning the job.

This allows Cron to run jobs with the SE-Linux permissions that the owner of the job has.

Cron is SELinux aware. It queries the policy to see to which domain it should transition when running a job.

It does not do a automatic domain transition because it does not actually execute the Cron job. Instead if uses "setexec" to domain transition.

It looks to see to which domains the Cron job file is a entrypoint. Then it needs to be able to process transition to that domain and then it checks the default login user domain of a user and with this information it determines in which domain to execute the job

By default:

allow cronjob_t user_cron_spool_t:file entrypoint;
allow crond_t cronjob_t:process transition;

Then there is a default context of for staff this is for example:

system_r:crond_t:s0        staff_r:cronjob_t:s0

But when you tune the policy with cron_userdomain_transition then these rules will be replaced by:

allow $1 user_cron_spool_t:file entrypoint;
allow crond_t $1:process transition;

Where $1 is the calling login user domain, and then it will look up the default login user domain and role, for staff this is for example:

# semanage user -l | grep staff_u
staff_u         user       SystemLow  SystemLow-SystemHigh           staff_r sysadm_r system_r unconfined_r

That means:

"staff_r:staff_t"

Then Cron daemon has permission to run the job in the staff domain with the staff role.

The benefits of running jobs in the login user domain are that now your Cron job can interact with your processes and operate on your files as if it were you interacting with your processes and operating on your files.

Needless to say that other SE-Linux rules that apply to you now also apply to your Cron jobs.

The policy may still have some rough edges but it was tested on Gentoo and is said to work. I did make some changes after that but hopefully i have not introduced regression.

Currently Redhat distributions do not have this cron_userdomain_transition boolean and i am not sure if she will adopt it.

Hard coded types create hard dependencies on selinux policy

Long time no see. I believe that applications like sandbox (sandbox_web_t) and sshd (chroot_user_t) hard code types. I do not like that but my personal opinion aside; This creates hard dependencies on SELinux policy. If you do not have a policy that provides these types then you will end up with broken functionality. I believe one example is that sandbox does not work in Debian because Debian selinux-policy does not provide the types that sandbox requires. That is all folks.

Git daemon and SELinux with RHEL6

RHEL6 does not ship with a manual page for configuring Git daemon SELinux policy, and so decided to publish a demonstration on youtube:

Part 1. Git system daemon, shared repositories.

http://www.youtube.com/watch?v=vgm89P5nbBQ

Part 2. Git session daemon, personal repositories.

http://www.youtube.com/watch?v=XHEPj80217o

By the way you can look at the manual page (source) here:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=blob;f=man/man8/git_selinux.8;h=e9c43b190c394f8ea7e68d9dd29f45c831340bf5;hb=ccadbe7d6ae709cdfd3b06d496477e069a2f13ee

selinux q&a

23:15 < someone> What's the difference between httpd_sys_rw_content_t and
httpd_sys_content_rw_t?
23:19 < dgrift> none
23:19 < dgrift> their aliased
23:19 < dgrift> theyre

frequently asked questions: selinux booleans in detail.

Q: "btw, anyone know if each of the selinux booleans are documented in detail somewhere?"

A: two levels of detail here:

1. semanage boolean -l | grep httpd_enable_homedirs
A written description (usually not very detailed) for the "httpd_enable_homedirs" boolean.

2. sesearch --allow -SC -T | grep httpd_enable_homedirs
All the "allow" type statement rules and type transition rules related to the "httpd_enable_homedirs" boolean. Very detailed but hard to interpret.

common issues -- part 1

22:13 < _Tassadar> hi
22:14 < _Tassadar> http://fedoraproject.org/wiki/SELinux/samba <- i'm reading this document, on how to
configure selinux to allow samba to share a certain directory
22:14 < _Tassadar> now i'd like to share /data/files so i issued chcon -t samba_share_t /data/files
22:14 < _Tassadar> it worked, according to ls -Z
22:14 < _Tassadar> but access is still denied
22:15 < _Tassadar> should i recursively set that label to every file in the share as well?
22:16 < SwifT> _Tassadar: (without reading the file) check your AVC denials on what is actually denied, but I
would say "yes, you'll probably want to recursively set the type"
22:17 < _Tassadar> SwifT: what is the best way to check my AVC denials?
22:17 < _Tassadar> it's a server, i don't have any gui tools
22:20 < dgrift> _Tassadar: try Fedora manage confined services
22:20 < _Tassadar> hm no new entries appear in /var/log/audit/audit.log
22:20 < SwifT> _Tassadar: depends on your system log configuration; try tail -f /var/log/messages or
/var/log/audit.log
22:20 < _Tassadar> some stuff from cron appears every five mins, but nothing from smb
22:20 < dgrift> _Tassadar this is a common issue
22:20 < dgrift> its this:
22:21 < dgrift> youve created a new mountpoint called /data
22:21 < dgrift> selinux doesnt know that location
22:21 < dgrift> and so it labels it with a type: default_t
22:21 < dgrift> this is a type for locations unknown to selinux
22:21 < dgrift> and selinux silently denies access to type default_t
22:22 < dgrift> because it should not happen
22:22 < dgrift> all locations should be labelled properly
22:22 < _Tassadar> ah
22:22 < _Tassadar> i see
22:22 < dgrift> so how to fix it?:
22:22 < _Tassadar> with restorecon probably
22:22 < dgrift> well you should start by labelling /data
22:22 < dgrift> what type to label it, that depends on your requirements for /data
22:23 < _Tassadar> well it's all user data
22:23 < dgrift> var_t should probably do
22:23 < dgrift> i see
22:23 < _Tassadar> no binaries, no devices
22:23 < _Tassadar> lots of mp3's :)
22:23 < dgrift> whats in /data?
22:23 < dgrift> only dirs?
22:23 < _Tassadar> yes
22:23 < _Tassadar> /data/home/user1 /data/home/user2
22:24 < _Tassadar> /data/home/public_area
22:24 < _Tassadar> /data/public_area i mean
22:24 < dgrift> whats your distro?
22:24 < _Tassadar> Fedora 14
22:24 < dgrift> ok heres my suggestion
22:24 < dgrift> what is /data/home/user1 labelled?
22:24 < _Tassadar> nothing yet
22:25 < dgrift> but thats a user home dir?
22:25 < _Tassadar> drwx------. joe users unconfined_u:object_r:samba_share_t:s0 joe
22:25 < _Tassadar> well
22:25 < _Tassadar> i labelled it samba_share_t
22:25 < dgrift> ok
22:25 < _Tassadar> that's what the docs told me to do :)
22:26 < dgrift> what do you want?
22:26 < _Tassadar> well it doesn't work yet
22:26 < dgrift> what do you want with those dirs?
22:26 < _Tassadar> i would like the user to be able to mount his directory from a windows workstation
22:26 < dgrift> what is your requirement
22:26 < dgrift> i see
22:26 < _Tassadar> users are allowed read/write access to their own directories
22:26 < dgrift> and not use it locally?
22:26 < _Tassadar> and also in the public_area
22:26 < _Tassadar> no
22:26 < dgrift> ok
22:26 < _Tassadar> no shell access
22:27 < _Tassadar> no local processes are to be started from /data
22:27 < dgrift> so label /data root_t and the other dirs in there samba_share_t
22:27 < _Tassadar> recursively?
22:27 < dgrift> semanage -a -t root_t -f -d /data
22:28 < dgrift> semanage -a -t samba_share_t "/data/home(/.*)?"
22:28 < dgrift> restorecon -R -v /data
22:28 < dgrift> that will label the data dir root_t
22:28 < _Tassadar> nice
22:28 < _Tassadar> what does root_t mean?
22:28 < dgrift> and /data/home and all below it samba_share_t
22:29 < dgrift> it means it the type for filesystem roots
22:29 < dgrift> basically its accessable by all
22:29 < _Tassadar> oh okay, that makes sense in this case
22:29 < dgrift> see if it work
22:29 < _Tassadar> what would the -a option do?
22:29 < _Tassadar> my system doesn't know -a
22:29 < _Tassadar> oh
22:29 < _Tassadar> it does
22:29 < dgrift> oops
22:30 < _Tassadar> something else is wrong
22:30 < dgrift> non i made a booboo
22:30 < _Tassadar> okay
22:30 < dgrift> semanage fcontext -a -t root_t -f -d /data
22:30 < dgrift> semanage fcontext -a -t samba_share_t "/data/home(/.*)?"
22:30 < dgrift> restorecon -R -v /data
22:31 < _Tassadar> lol okay that could take a while
22:31 < _Tassadar> i'll run it without -v
22:31 < dgrift> hopefully it works for you
22:31 < dgrift> yes ok
22:31 < _Tassadar> it's a 11TB mount ;)
22:31 < dgrift> ouch....
22:31 < dgrift> all data on it?
22:31 < _Tassadar> yeah, no worries though, i'm not in a hurry
22:32 < _Tassadar> it's 60% used ;)
22:32 < dgrift> geez
22:32 < dgrift> i hope we get this right first time...
22:32 < dgrift> might want to test first
22:32 < dgrift> with a small dir
22:32 < _Tassadar> heh
22:32 < _Tassadar> i suppose so
22:32 < _Tassadar> ....
22:33 < dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:33 < dgrift> chcon -t root_t /data
22:34 < _Tassadar> okay i'll try that
22:34 < dgrift> errr
22:34 < dgrift> its like this:
22:34 < dgrift> chcon -t root_t /data
22:34 < dgrift> chcon -t /data/home
22:34 < dgrift> err
22:34 < _Tassadar> ?
22:34 < _Tassadar> lol
22:34 < dgrift> chcon -t samba_share_t /data/home
22:34 < dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:35 < dgrift> so three lines
22:35 < _Tassadar> yeah i understand, but restorecon is already running so /data and /data/home are already done
;)
22:35 < dgrift> because theres 3 dirs
22:35 < _Tassadar> i just tried with a small userdir and it works great !
22:35 < dgrift> ok
22:35 < _Tassadar> but, how do i keep everything neat
22:35 < _Tassadar> does restorecond do that?
22:35 < _Tassadar> i mean every time someone adds a file
22:36 < _Tassadar> it should get the right label immediately
22:36 < dgrift> it inherites the type of the parent dir
22:36 < dgrift> so should be fine
22:36 < _Tassadar> ah i see
22:36 < _Tassadar> so what does restorecond do then?
22:36 < dgrift> try it
22:36 < dgrift> well it watches directories for mislabelled files
22:36 < dgrift> but in your case its not applicable
22:37 < dgrift> because theres only one type
22:37 < _Tassadar> -rw-rw----. joe users unconfined_u:object_r:samba_share_t:s0 zzzzz.txt
22:37 < _Tassadar> yeah that works
22:37 < dgrift> samba_share_t
22:37 < _Tassadar> ah mislabelled, so not unlabelled
22:37 < _Tassadar> i understand
22:37 < _Tassadar> real 5m32.340s
22:37 < dgrift> well and unlabelled aswell
22:37 < _Tassadar> done :)
22:37 < dgrift> fast system
22:37 < _Tassadar> yeah :)
22:38 < dgrift> i should blog about this issue
22:38 < dgrift> its very common
22:38 < _Tassadar> definately
22:39 < dgrift> and people wonder why its not logging denials
22:39 < _Tassadar> yeah and the fact that audit.log doesn't show anything makes it hard to track for newbies like
me
22:39 < _Tassadar> exactly :)
22:39 < dgrift> can i use this chat log?
22:39 < dgrift> to publish?
22:39 < _Tassadar> errrr :)
22:39 < _Tassadar> i suppose

Yet another step by step introduction to policy development.

Due to several requests for guides to writing SELinux policy i have decided to create another screen cast detailing how to create a policy for a user application, and some of the things that may help one get familiar with policy writing.

As per usual by now, it is just a amateur production for amateurs. These recordings are pretty boring and long. I do advise that you view the whole thing in the proper order. Because things may not be explained well all the time, but most of it should become more clear in the course of the series.

Sometimes i make mistakes that i later notice. By the end of the series everything is pretty much sorted out (except atleast one pretty minor issue that i consider as an exercise to the watcher to troubleshoot and solve).

Also note that i encountered a conflict with restorecond -u (run in a gnome-session) with regard to labelling a file in the user home directory. I worked around that issue, but it will work fine when one logs out and back in, when it occurs.

part 1. Setting up an optimal environment for policy writing and in the mean time i explain my view on policy writing and every aspect of it.

http://www.youtube.com/watch?v=s4EyoW_7riQ

part 2. Do it yourself: create a simple script and write raw policy for it. Introduction to type transition, allow, dontaudit and other type statements. A start at translating raw policy that SELinux understands into policy that is maintainable and readable by humans and that is scalable in a modular environment.

http://www.youtube.com/watch?v=G5gUt1-ttGg

part 3. Proceed with translation of raw policy to m4 macro language powered policy. Merge our loadable policy module into upstream tresys reference policy.

http://www.youtube.com/watch?v=nbFnchVAgYs

part 4. troubleshoot remaining issues and fix them.

http://www.youtube.com/watch?v=rUGBgzTr92A

If you have specific question with regard to the series above feel free to ask for clarification.