linux-kernel - Re: Friendlier EPERM

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]

Message-Id: <201301121408.GCH51539.SFOVOFLJMOFHQt@I-love.SAKURA.ne.jp>
Date:	Sat, 12 Jan 2013 14:08:50 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	eparis@...hat.com
Cc:	linux-kernel@...r.kernel.org, dwalsh@...hat.com,
	dmalcolm@...hat.com, sds@...ho.nsa.gov, segoon@...nwall.com,
	linux-security-module@...r.kernel.org
Subject: Re: Friendlier EPERM - Request for input

Eric Paris wrote:
> On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> > The reason I think is that people turn off LSMs because they are using LSMs
> > without understanding "what the current configuration is" and/or "how to change
> > configuration". People do not spend (or cannot afford spending) resources for
> > understanding LSM's configuration.
> 
> This is not the point I am arguing.  This is not about LSMs, how hard
> they are to configure, or how to 'fix' them.  It certainly isn't about
> how one LSM is better, easier, or superior to another.  This is about
> getting more information in userspace when operations fail.  I'll quote
> an off list e-mail I received:
> 
> Friendlier/more complete error messages would eliminate an awful lot of
> digging around trying to figure *what* the problem is, preparatory to
> discerning *where* the problem is and *how* to fix it.

I agree that having a mechanism to allow the caller to know the reason of
failure would be nice. What I'm worrying is that they will simply disable the
LSM (e.g. "setenforce 0") even if users are promptly told (via e.g. perror())
that "Cannot open foo for reading: Denied by SELinux" unless very serious
effort to allow users to understand "what the current configuration is" and
"how to change configuration" is made.

While SELinux provides many boolean configuration options, basic stance of
SELinux sounds (at least to me) that "users need not to understand/know SELinux
configuration; we won't ask users to understand/know SELinux configuration".
This is horrible for enterprise systems because who builds a system and who
uses/maintains that system are generally different (and therefore builder's
administration skill and user/maintainer's administration skill may drastically
differ). The person who builds a system is unlikely contactable when the person
who uses/maintains that system encountered a trouble. My fear is that
"Friendlier EPERM" results in saving only debugging time until LSM is disabled
by the builder/user/maintainer.
--
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/