Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 396643

Summary: layman lacks SELinux permissions for searching home dirs
Product: Gentoo Linux Reporter: Stan Sander <stsander>
Component: HardenedAssignee: SE Linux Bugs <selinux>
Status: VERIFIED FIXED    
Severity: normal CC: dolsen
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Patch to allow search of user home dirs for portage_fetch_t
strace of layman adding hardened-development overlay

Description Stan Sander 2012-01-01 00:00:08 UTC
Created attachment 297497 [details]
Patch to allow search of user home dirs for portage_fetch_t

When adding new overlays with layman it fails due to being unable to search user home dirs.  With the attached patch applied, layman works correctly.

#layman -a hardened-development

 * Adding overlay,...
 * Running Git... # /usr/bin/git clone git://git.overlays.gentoo.org/proj/hardened-dev.git /var/lib/layman/hardened-development
fatal: Could not change back to '/root': Permission denied
 * Failure result returned from Git
 * Deleting _empty_ directory "/var/lib/layman/hardened-development"
 * Adding repository "hardened-development" failed!

 * CLI: Errors occured processing action add
 * Adding repository "hardened-development" failed!

Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.144:9480): avc:  denied  { search } for  pid=7395 comm="layman" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.184:9481): avc:  denied  { getattr } for  pid=7396 comm="eselect" path="/root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.204:9482): avc:  denied  { search } for  pid=7398 comm="eselect" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.204:9483): avc:  denied  { search } for  pid=7398 comm="eselect" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.204:9484): avc:  denied  { search } for  pid=7398 comm="eselect" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.207:9485): avc:  denied  { search } for  pid=7399 comm="eselect" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.224:9486): avc:  denied  { search } for  pid=7404 comm="eselect" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.301:9487): avc:  denied  { search } for  pid=7395 comm="layman" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.731:9488): avc:  denied  { search } for  pid=7406 comm="git" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Dec 31 16:35:51 siren kernel: type=1400 audit(1325374551.731:9489): avc:  denied  { search } for  pid=7406 comm="git" name="root" dev=sda1 ino=4290561 scontext=stan:sysadm_r:portage_fetch_t tcontext=root:object_r:user_home_dir_t tclass=dir
Comment 1 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-01 09:25:13 UTC
Hi Stan,

I can't seem to reproduce this:

hpl ~ # layman -a hardened-development
* Running... # /usr/bin/git clone git://git.overlays.gentoo.org/proj/hardened-dev.git /var/lib/layman/hardened-development
Cloning into /var/lib/layman/hardened-development...
remote: Counting objects: 9911, done.
remote: Compressing objects: 100% (5866/5866), done.
remote: Total 9911 (delta 4839), reused 7159 (delta 3425)
Receiving objects: 100% (9911/9911), 4.49 MiB | 343 KiB/s, done.
Resolving deltas: 100% (4839/4839), done.
* Successfully added overlay "hardened-development".
hpl ~ # layman -d hardened-development
* Deleting directory "/var/lib/layman/hardened-development"
* Successfully deleted overlay "hardened-development".

I don't have any rights for portage_fetch_t towards user_home_dir_t or user_home_t. Do you by any chance have an overlay in your home directory?

I even executed the command from within /root.
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-01 09:28:58 UTC
Also, what version of layman are you using, and would it be possible to get a backtrace of any kind so we might find the source of the error?
Comment 3 Stan Sander 2012-01-02 16:42:32 UTC
I've got app-portage/layman-2.0.0_rc3.  I hadn't used layman in quite a while and had uninstalled it some time ago, so this is really like a fresh install of layman.  I'll upload a trace shortly.
Comment 4 Stan Sander 2012-01-02 16:45:08 UTC
Created attachment 297703 [details]
strace of layman adding hardened-development overlay
Comment 5 Brian Dolbec (RETIRED) gentoo-dev 2012-01-02 22:11:37 UTC
If it's something I'm doing different in the 2.0 api causing the the trouble, I'd like to know. Changes to the actual low level VCS modules was minimal.  Most all changes were to the mid and high level layman code.

From the original layman output, the error occurred in git.  Seemingly after it cloned the repo and tried changing directory back to the root user's home dir.  If I understand that right.
Comment 6 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-03 18:56:30 UTC
Stan,

if you run layman when you're in /var/lib, does that work? Not that this is the solution I'm going to suggest, but it helps finding out where to go to.

Brian,

is it possible that layman 1.4.1 first changes directories elsewhere before calling git, but in the 2.0 series doesn't anymore (or if it does, goes back to the current working directory before calling git)?
Comment 7 Stan Sander 2012-01-03 21:03:38 UTC
Yes, it does work from /var/lib.  It does not work from /root or from /home/stan (home area of my regular user account before using su)  I did a little additional testing and it does not work if $CWD is somewhere that portage_fetch_t does not have search permissions.
Comment 8 Brian Dolbec (RETIRED) gentoo-dev 2012-01-03 21:57:16 UTC
I am quite sure that I did not change that portion of the code.  If you look at Stan's output you will see that layman does not change directories. It passes the target directory to Git, etc. On the command line.  It is Git that is running into the error. Layman prints the actual command line that it runs in a subprocess.

I can check when I get home from work.  Posting from my phone :)
Comment 9 Brian Dolbec (RETIRED) gentoo-dev 2012-01-04 02:48:56 UTC
I've been comparing the code between 1.4.1 and trunk.  There is almost no difference in that code.  Nothing that could cause the trouble.

Further, while following the code sequences, comparing the output from both Stan's and Swen's runs, I was able to confirm that the error is coming from the git command being run in the subprocess.

So, That leaves 2 other unknowns for me.  What the git versions you both are using, and maybe some environment variable(s) causing the problem.  Layman passes the environment it gets with possibly some environment updates that might be needed to the subprocess.Popen() call
Comment 10 Brian Dolbec (RETIRED) gentoo-dev 2012-01-04 04:33:41 UTC
Also, it will "cd to/the/dir  && run/the/command..." for syncing in the subprocess.Popen() call, not in the running layman code.  That is for 1.4.x and 2.0.0*

In layman-2.0.0. it also adds the option to run other command(s) as postadd/postsync hooks.  Stan's original output indicates that it was git that failed.  But, just in case... Do you have any postadd/postsync options defined in /etc/layman/layman.cfg?
Comment 11 Stan Sander 2012-01-04 17:07:23 UTC
Sorry I didn't check my messages last night.  I am running git-1.7.8.1 and I do not have any postadd/postsync options defined, just a stock layman install. 
As I was printing out and reviewing the environment to post here, I discovered the problem.  I had . in roots path!  :O  Seems I had at some point copied a .bashrc file into /root and missed that detail.  Corrected that and layman no longer has a problem adding/updating an overlay.  

Sorry about the noise.
Comment 12 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-04 19:18:30 UTC
I run git 1.7.3.4-r1 here.

Okay, so we know it's part of the working directory the user is at at the time of execution. For SELinux, this is somewhat troublesome, because we can't really tell users to first go into a directory that the portage_fetch_t domain has search access to. Otoh, granting portage_fetch_t search access on all possible domains might also be a bit too much.

I'll update git and see if I can find where it does this, but I'm not sure about a proper solution yet. But if necessary, I'll add in a files_search_all(portage_fetch_t).
Comment 13 Stan Sander 2012-01-04 19:22:59 UTC
Swift,

From my comment #11, the problem actually is having . in the (presumably root) user's path.  That is a scenario that we don't want.  As long as . isn't in the path, then everything is fine.
Comment 14 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-04 20:21:55 UTC
Are you certain?

I am now running layman and git in ~arch and, without "." in PATH, have the issue now as well. But as can be seen from earlier comments and Brian's feedback, this is most likely nothing to do with layman and all with git.

I find a few hits on the Internet about similar issues (about git), but their resolution currently is to switch working directory before calling git.
Comment 15 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-04 20:31:45 UTC
Seems to be in git's abspath.c::real_patch() function... which is called quite often (including in the cloning phase).

The function is to resolve a given path and make sure it is absolute and not containing any links.

I could debug the sucker and see which particular call is causing this, but I think i'm just going to grant the rights to search user_home_dir_t (not all possible directories, since it might not be triggered that much and this user_home_dir_t will be one of the most common cases).
Comment 16 Stan Sander 2012-01-04 20:34:54 UTC
Sorry, my bad.  I thought I had backed out the permissions for searching home dirs but in fact I hadn't.  I still do have the issue, and from the strace I sent I believe it is clearly with git which is only being called by layman.  Here is my env as requested earlier:

MANPATH=/etc/java-config-2/current-system-vm/man:/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.22/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man:/etc/java-config/system-vm/man/
LINGUAS=en en_US
TERM=xterm
SHELL=/bin/bash
OLDPWD=/bacula
ANT_HOME=/usr/share/ant
LC_ALL=en_US.UTF-8
USER=root
PRELINK_PATH_MASK=/usr/lib64/libfreebl3.so:/usr/lib64/libnssdbm3.so:/usr/lib64/libsoftokn3.so
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
GDK_USE_XFT=1
CONFIG_PROTECT_MASK=/etc/gentoo-release /etc/sandbox.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/terminfo /etc/ca-certificates.conf /etc/texmf/web2c /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/revdep-rebuild
PAGER=/usr/bin/less
XDG_CONFIG_DIRS=/etc/xdg
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/sbin:/sbin:/usr/X11R6/bin
PWD=/root
INPUTRC=/etc/inputrc
JAVA_HOME=/etc/java-config-2/current-system-vm
EDITOR=vi
JAVAC=/etc/java-config-2/current-system-vm/bin/javac
LANG=en_US.UTF-8
GSETTINGS_BACKEND=gconf
HISTIGNORE=&:exit
AUDIODRIVER=oss
GPG_TTY=/dev/pts/1
HOME=/root
SHLVL=2
JDK_HOME=/etc/java-config-2/current-system-vm
JAVACC_HOME=/usr/share/javacc/
LOGNAME=root
LESS=-R -M --shift 5
XDG_DATA_DIRS=/usr/local/share:/usr/share
LESSOPEN=|lesspipe %s
R_HOME=/usr/lib64/R
INFOPATH=/usr/share/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.22/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info
DISPLAY=:0
LADSPA_PATH=/usr/lib64/ladspa
OPENGL_PROFILE=xorg-x11
QT_PLUGIN_PATH=/usr/lib64/kde4/plugins
RUBYOPT=-rauto_gem
USB_DEVFS_PATH=/dev/bus/usb
SANE_CONFIG_DIR=/etc/sane.d
Comment 17 Brian Dolbec (RETIRED) gentoo-dev 2012-01-05 01:29:22 UTC
I can offer another possible solution.  Layman already has code in place to make hte subprocess change it's working directory.  It does this for syncing, but not for adding.  All it will take is to add "cwd=base" to the self.run_command call parameters.

.../site-packages/layman/overlays/git.py 
line 71:
    self.run_command(self.command(), args, cmd=self.type),

to:

    self.run_command(self.command(), args, cmd=self.type, cwd=base),


That will force a "cd ${base} && git..." instead of just running git.

It is also possible to force all repo types to do this when adding a new overlay.  The 1.4.2 release could easily be patched the same as 2.0.0.  I had been neglecting doing a stable request for 1.4.2, so could do an r1 bump with a patch for this if that is preferable for selinux.

Since I do not have an selinux install to test with.  Could either one/both of you test that that change works correctly?
Comment 18 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-05 17:40:12 UTC
This works, thanks!

I don't think there's an immediate need to do this for stable-layman since the git where it occurs isn't stable either.
Comment 19 Brian Dolbec (RETIRED) gentoo-dev 2012-01-06 08:20:50 UTC
Done, added the cwd-base parameter in layman/overlays/git.py's add().

 commit http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=commit;h=77fd9c78984df218d33520c6dce7a8a0c630c456

This is available now in layman-9999 and will be included in 2.0.0_rc4.
Comment 20 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-10 19:44:30 UTC
Thanks! I'm going to mark this as IN_PROGRESS until layman 2.0.0_rc4 is available as ~arch (in which case it'll become VERIFIED:TESTREQ).
Comment 21 Sven Vermeulen (RETIRED) gentoo-dev 2013-03-29 09:41:51 UTC
layman-2 is stable