lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54B3EDF4.2000801@tycho.nsa.gov>
Date:	Mon, 12 Jan 2015 10:53:24 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Christopher J. PeBenito" <cpebenito@...sys.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Stephen Smalley <stephen.smalley@...il.com>,
	Paul Moore <pmoore@...hat.com>,
	selinux <selinux@...ho.nsa.gov>,
	James Morris <james.l.morris@...cle.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: noisy selinux messages on tmpfs mount.

On 01/12/2015 09:51 AM, Christopher J. PeBenito wrote:
> On 1/9/2015 3:47 PM, Stephen Smalley wrote:
>> On 01/09/2015 02:13 PM, Dave Jones wrote:
>>> On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
>>>  
>>>  > On Thu, Jan 8, 2015 at 2:39 PM, Paul Moore <pmoore@...hat.com> wrote:
>>>  > > On Thursday, January 08, 2015 02:34:57 PM Paul Moore wrote:
>>>  > >> On Thursday, January 08, 2015 02:08:22 PM Dave Jones wrote:
>>>  > >> > systemd has started mounting a tmpfs in /run/user/<uid> every time a
>>>  > >> > session begins.  So after ssh'ing into a box a number of times, dmesg
>>>  > >> > looks like this..
>>>  > >> >
>>>  > >> > [...] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>>>  > >> > [...] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>>>  > >>
>>>  > >> {snip}
>>>  > >>
>>>  > >> > What's a good solution to stopping this spew ? printk_once doesn't seem
>>>  > >> > like a good fit, in case someone is doing different labelling behaviours
>>>  > >> > between mounts.
>>>  > >> >
>>>  > >> > Could we only print it if the mount is being done with non-default
>>>  > >> > behaviour perhaps?
>>>  > >>
>>>  > >> I'm very curious to hear Stephen's opinion on the issue, but I wonder how
>>>  > >> much this would honestly impact us if we removed this message in the case
>>>  > >> where we mount the filesystem with a known labeling behavior.
>>>  >
>>>  > We already reduced that message to KERN_DEBUG.  Is that not sufficient?
>>>
>>> That doesn't really help with the flooding of dmesg, so no.
>>> I should also note that it's not just logging in that creates a new
>>> session, it also seems to be getting triggered by cron jobs, or
>>> whatever the systemd replacement is.
>>
>> Fair enough.  I think we can likely get rid of it then.
> 
> Are you saying completely get rid of the message in all cases?  If so,
> how is a user supposed to debug situations where they mount a filesystem
> and labeling doesn't work (i.e. no security label support or policy
> hasn't been updated for that fs)?  Is there going to be another place to
> look see what the labeling behavior is for all mounted filesystems?

In most cases, they can extract the information directly from the policy
via seinfo or their favorite policy tool.  For mountpoint labeling, the
printk in question only tells them that mountpoint labeling was used,
not the specific option and value, so reading /proc/self/mounts is more
informative.  /proc/self/mounts will also tell them whether the
filesystem "supports" labeling via the seclabel option.  So I don't
believe it offers us any information that isn't available elsewhere.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ