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: <1357835679.1342.45.camel@localhost>
Date:	Thu, 10 Jan 2013 11:34:39 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
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

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.

There are so many things that might go into fixing problems in an LSM.
That's what you are talking about, but it isn't relevant here.  This is
about knowing WHAT the problem is, maybe helping with where and how.
And this isn't just about LSM.  Heck, LSMs are just a small part of it.
I want extended errno interface to talk about DAC, capabilities, ACLs,
LSMs, everything!

> > The audit log is complete crap from a usability PoV.  If a web admin is
> 
> TOMOYO's audit log is very useful. TOMOYO is a security tool but is also useful
> for education/training/debugging/development/profiling etc.

The TOMOYO audit log is a very poor fit for this as well.  I'm not
trying to be rude, but there is no reasonable way for applications to
use it, it is TOMOYO specific, and it doesn't cover non-LSM errors.  I
want applications like httpd to be able to put what went wrong in its
log message.  I want python to be able to get extended information and
present that up the stack.  Nothing we have today comes close.  My
proposal isn't perfect, it suffers from the same problems as errno
(except even worse because it is harder to save and restore), but at
least it will usually be helpful...

-Eric

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