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
| ||
|
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/
Powered by blists - more mailing lists