| 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
| ||
|
Date: Mon, 28 Dec 2009 20:51:49 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: Valdis.Kletnieks@...edu Cc: serge@...lyn.com, serue@...ibm.com, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org Subject: Re: A basic question about the security_* hooks Thank you for your opinion. Valdis.Kletnieks@...edu wrote: > Usually, the right answer is to fix XYZ, not try to load ZQW on top of it. Yes, to fix SELinux is the right answer if we can integrate TOMOYO into SELinux. But SELinux had been advertised as label based access control and had been rejecting pathname based access control. I doubt SELinux wants to integrate pathname based access control. Screwed up due to improper policy configurations / conflicts and unable to recover cannot be reasons to reject enabling multiple LSM modules. Such situations do happen even single LSM module. There are lots of access control mechanisms outside LSM. Executing SELinux's restorecon can fail due to ENOMEM. The restorecon may not be executed due to "mount -o noexec". The restorecon may be replaced by "mount --bind /bin/true /sbin/restorecon". The restorecon may not work as expected due to improper LD_PRELOAD environment. Changing xattr of an inode may fail due to EIO. Note that SELinux or TOMOYO is not the only factor that makes operations fail. For SELinux, TOMOYO is one of factors that make operations for SELinux fail. For TOMOYO, SELinux is one of factors that make operations for TOMOYO fail. SELinux and TOMOYO have to prepare for bad consequence when failures like ENOMEM, EIO, EACCES, EPERM occurred outside SELinux or TOMOYO. People enable SELinux and/or TOMOYO by accepting the risk shown above. Those who think the benefit of enabling SELinux is larger than the risk of enabling SELinux enable SELinux. Those who think the risk of enabling SELinux is larger than the benefit of enabling SELinux don't enable SELinux. Those who think the benefit of enabling both SELinux and TOMOYO is larger than the risk of enabling both enable both. Those who think the risk of enabling both is larger than the benefit of enabling both don't enable both. It is Linux users who evaluate, not Linux kernel developers. Keeping SELinux and TOMOYO mutually exclusive deprives Linux users of chances to evaluate, and prevents Linux kernel developers from coming up with new ideas/implementations. Why not to give Linux users choice for enabling both? Serge E. Hallyn wrote: > Why do you compose the two? I assume you went to the trouble because > you have a specific use case, a definite advantage? SELinux is useful for protecting daemons as ready made policy is distributed, but console/ssh sessions are not protected (unconfined_t) for most systems. TOMOYO is useful for restricting console/ssh sessions as administrators can develop policy by their own. Both SELinux and TOMOYO have ability to cover all processes (from /sbin/init till /sbin/poweroff) or targeted processes (e.g. only daemons). But SELinux is not widely used for protecting all processes. TOMOYO can provide some protection for processes which SELinux doesn't protect. Also, people know we sometimes need to restrict string parameters for avoiding unwanted consequence. TOMOYO can pay attention to string parameters whereas SELinux can't. Regards. -- 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