[DSE-Dev] Bug#781779: not grave

[Russell Coker]

On Tue, 15 Sep 2015 07:56:09 PM Andre Florath wrote:
> > Firstly this is not a grave bug.  Most of the benefits of SE Linux are on
> > servers so even if it didn't work for a graphical login that wouldn't be
> > a grave bug.
> 
> I completely disagree here!
> A large part of Debian installations is used as desktop [1].
> Just there when using EMails and Web-Browsers SELinux is of great help.

https://www.debian.org/Bugs/Developer#severities

The above URL explains that grave means "makes the package in question 
unusable or mostly so, or causes data loss, or introduces a security hole 
allowing access to the accounts of users who use the package".

SE Linux is very usable on headless servers.  I don't think that "mostly 
unusable" equates to "doesn't work on the subset of machines that I want it to 
work on".

If someone waws hunting for a way of marking a SE Linux bug as grave they 
would look for a data loss bug.  It's not at all uncommon for a bug in policy 
to prevent a process from writing something it was supposed to write.

> > Finally I can't do anything more about this without even knowing what
> > desktop environment is having a problem.  I need to know what XDM
> > program and what desktop environment are being used and if it works with
> > a different XDM or different desktop environment (twm is good for
> > testing).
> 
> I'm using the default :-)
> Minimal VM installation and then:
> # apt-get install task-desktop

What I really want to know in such cases is whether other desktop environments 
or other XDM programs work.  If one program breaks it could be an issue with 
that program.  If multiple programs break it could be something more basic.

> #============= NetworkManager_t ==============
> allow NetworkManager_t NetworkManager_initrc_exec_t:dir { read search };
> allow NetworkManager_t systemd_logind_t:dbus send_msg;
> allow NetworkManager_t systemd_logind_var_run_t:dir { read search };

I'll have to install NetworkManager and work on the policy for it.  It's not 
something that can be done via bug reports.  For the moment try not using it.

> #============= alsa_t ==============
> 
> #!!!! The source type 'alsa_t' can write to a 'dir' of the following types:
> # pulseaudio_home_t, alsa_tmp_t, alsa_var_lib_t, var_lock_t, etc_t,
> tmpfs_t, user_home_dir_t, root_t, tmp_t, user_tmp_t, pulseaudio_tmpfsfile,
> alsa_etc_rw_t, user_home_t
> 
> allow alsa_t var_run_t:dir write;

What is the name of the directory in question?  What is the name of the 
program running in the alsa_t domain?

> #============= rtkit_daemon_t ==============
> allow rtkit_daemon_t xdm_t:process setsched;
> 
> #!!!! The source type 'systemd_logind_t' can write to a 'dir' of the
> following types: # var_auth_t, cgroup_t, user_tmp_t, udev_rules_t,
> init_var_run_t, udev_var_run_t, systemd_logind_var_run_t,
> systemd_logind_sessions_t
> 
> allow systemd_logind_t tmpfs_t:dir write;
> allow systemd_logind_t user_tmpfs_t:dir read;
> allow systemd_logind_t user_tmpfs_t:file getattr;
> allow systemd_logind_t xdm_tmpfs_t:dir read;
> allow systemd_logind_t xdm_tmpfs_t:file getattr;

What are the names of the directories in question?  Use the -v option to 
audit2allow.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/