linux-kernel - Re: noisy selinux messages on tmpfs mount.

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Jan 2015 10:24:29 +0100
From:	Dominick Grift <dac.override@...il.com>
To:	Paul Moore <paul@...l-moore.com>
Cc:	Paul Moore <pmoore@...hat.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Stephen Smalley <sds@...ch.ncsc.mil>,
	James Morris <james.l.morris@...cle.com>,
	selinux <selinux@...ho.nsa.gov>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: noisy selinux messages on tmpfs mount.

On Sat, 2015-01-10 at 10:11 +0100, Dominick Grift wrote:
> On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote:
> > systemd has taken over cron too?  I suppose that is a logical extension, 
> > but still...
> 
> That is were i think davej is wrong. Here is what i think is the
> scenario with cron.
> 
> Cron runs jobs on behalf root. Root is generally not logged in all the
> time. So every time cron performs a job on behalf of root (hourly etc),
> systemd logind creates /run/user/0 and mounts tmpfs on it, when the job
> is done, tmpfs is unmounted and /run/user/= removed.
> 
> In that sense cron acts as kind of a login program.
> 
> Where i think davej might be wrong is that this would also happen with
> systemd's replacement for cron: timers.
> 
> I suspect that systemd logind does not create 0 user runtime directory
> everytime a timer is triggered, as opposed to cron.
> 
> with regard to normal user timers.Those really only work if you enable
> lingering on the systemd --user daemon with logind. This means that in
> practice the user is always logged in from a systemd logind user runtime
> directory point of view (e.g. /run/user/$UID is always there for a user
> that has a lingering systemd session daemon instance)
> 
> In practice , i suspect that this means that, although now with cron
> were seeing logind mount tmpfs whenever some job of behalf of root is
> run if root is not physically loged in (which is often), that this would
> not be the case if we got rid of cron and if it would be replaced by
> systemd timers
> 
> One might ask the question: why does logind create a root user runtime
> directory every time cron runs a job on behalf of root. Is that really
> required?
> 

Never the less. On systems with many users login and out regularly you
will see this message often. because when a user logs in /run/user/$UID
is created and tmpfs is mounted on it. When the user logs out tmpfs is
unmounted, and /run/user/$UID is removed ... unless that users' systemd
--user instance is lingering.

> > 
> > --
> > paul moore
> > www.paul-moore.com
> > 
> > 
> > 
> > On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@...il.com> wrote:
> > 
> > > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > > > >  > 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.
> > > >
> > > > I wonder if this is cron/systemd/whatever creating a new namespace and
> > > > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> > > limit the
> > > > messages to the initial namespace ... ?
> > > >
> > >
> > > It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> > > mounting a tmpfs on it)
> > >
> > >
> > >
> > >
> > > --
> > > 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/
> > 
> > 
> 
> 


--
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/