From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 218AB13873B for ; Tue, 4 Mar 2014 16:24:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87B4DE0B77; Tue, 4 Mar 2014 16:24:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BBACCE0A98 for ; Tue, 4 Mar 2014 16:23:59 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 617) id 0D19D33F9C3; Tue, 4 Mar 2014 16:23:59 +0000 (UTC) Date: Tue, 4 Mar 2014 16:23:58 +0000 From: Sven Vermeulen To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] Incorrect contexts in /run Message-ID: <20140304162358.GB13432@gentoo.org> Mail-Followup-To: gentoo-hardened@lists.gentoo.org References: <20140302213622.GA2191@imap.bennyp.org:5982> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20140302213622.GA2191@imap.bennyp.org:5982> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: e9680ce5-1c28-4135-ad7d-af74244026fb X-Archives-Hash: d265d438351f3686f10c2fb7da214e2d On Sun, Mar 02, 2014 at 04:36:23PM -0500, Ben Pritchard wrote: > I have a few files/directories in /run (or /var/run) that do not have the > correct selinux contexts. Notably, files belonging to samba and fail2ban, > but there may be others. > > I thought this might be related to the /run migration bug (424173) but > it seems to restore to the correct contexts, just that the files are not > created with the correct contexts. How are the contexts of these files > usually managed? > > > #output from matchpathcon: > /run/dbus.pid has context system_u:object_r:system_dbusd_var_run_t, should be <> > /run/fail2ban has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:fail2ban_var_run_t > /run/lvm has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:var_run_t > /run/ntpd.pid has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:ntpd_var_run_t > /run/privoxy-tor.pid has context system_u:object_r:privoxy_var_run_t, should be <> > /run/samba has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:smbd_var_run_t > /run/saslauthd has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:var_run_t > /run/sepermit has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:pam_var_run_t > /run/sshd.pid has context system_u:object_r:sshd_var_run_t, should be <> > /run/syslog-ng.ctl has context system_u:object_r:devlog_t, should be system_u:object_r:syslogd_var_run_t The matchpathcon and restorecon actions should be the same: matchpathcon tells the user what the value should be, restorecon applies this value. When matchpathcon sais that a label should be <> then no specific action is taken. This is usually the case for files that get a file context assigned by the process that creates the file, and which might be different depending on circumstances. Or in other words, SELinux keeps the label as-is, even during a restorecon operation. For instance: # matchpathcon > /run/ntpd.pid has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:ntpd_var_run_t > /run/samba has context system_u:object_r:initrc_var_run_t, should be system_u:object_r:smbd_var_run_t # restorecon > restorecon reset /run/ntpd.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:ntpd_var_run_t > restorecon reset /run/samba context system_u:object_r:initrc_var_run_t->system_u:object_r:smbd_var_run_t > restorecon reset /run/samba/nmbd.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:nmbd_var_run_t > restorecon reset /run/samba/smbd.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:smbd_var_run_t In order to have the files immediately with the right context, we need to find out which process (actually, which SELinux domain) is responsible for creating the files in the first place (and thus having the files stored with a particular label). For most of the files, this is easy to deduce. For instance, /run/ntpd.pid got label initrc_var_run_t, so it's most likely initrc_t (the domain used for init scripts) that created the PID file. And if I'd take a long guess, it would be /etc/init.d/ntpd ;-) In order to fix this, we need to add in a statement that equals to: #v+ files_pid_filetrans(initrc_t, ntpd_var_run_t, file, "ntpd.pid") #v- Sadly, this statement calls two types not part of the same module (initrc_t is of the "init" module while ntpd_var_run_t is of the "ntp" module). Coding-style wise, this is not allowed, so we need to seek (or write) another statement that only calls types of the same module. For directories, we created an "init_daemon_run_dir" call. It looks like we might need to introduce a similar one for files, namely "init_daemon_run_file". Then the call would be (inside ntp.te): #v+ init_daemon_run_file(ntpd_var_run_t, "ntpd.pid") #v- For the samba directory, we can already use the init_daemon_run_dir() call, as /run/samba has context initrc_var_run_t (thus also created most likely by the smb* or other samba related init scripts). I'll put your mail in a bugreport and might even work on it this evening (depending on available time). I'll get back to you when the necessary commits have occurred ;-) Wkr, Sven Vermeulen