Re: TOMOYO Linux Security Goal

2007-12-26 Thread Serge E. Hallyn
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > This document is intended to specify the security goal that TOMOYO Linux is > trying to achieve, so that users can evaluate whether TOMOYO Linux will meet > their needs, and kernel developers can evaluate whether TOMOYO Linux deserved > to be in-tree. >

empty capability sets and suid-0-bit binaries

2007-12-26 Thread Chris Friedhoff
Hello, in updating the documetation http://www.friedhoff.org/posixfilecaps.html I noticed a change in the behavior. There was the behavior, when the extended attribute capability was present but with empty sets, even a suid-0-bit binary was not having the right to request a call for which capabil

POSIX file capabilities for directories

2007-12-26 Thread Chris Friedhoff
Hello, in updating the documentation http://www.friedhoff.org/posixfilecaps.html I discovered that it is possible to give directories through setcap also the extended attribute capability and therefor grant them capabilities. Is this is intended or maybe not ? If it's intended, what is the benefit

Re: POSIX file capabilities for directories

2007-12-26 Thread Serge E. Hallyn
Quoting Chris Friedhoff ([EMAIL PROTECTED]): > Hello, > > in updating the documentation > http://www.friedhoff.org/posixfilecaps.html I discovered that it is > possible to give directories through setcap also the extended attribute > capability and therefor grant them capabilities. > Is this is in

Re: empty capability sets and suid-0-bit binaries

2007-12-26 Thread Serge E. Hallyn
Quoting Chris Friedhoff ([EMAIL PROTECTED]): > Hello, > > in updating the documetation http://www.friedhoff.org/posixfilecaps.html > I noticed a change in the behavior. > > There was the behavior, when the extended attribute capability was > present but with empty sets, even a suid-0-bit binary w

Re: POSIX file capabilities for directories

2007-12-26 Thread Andrew Morgan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: > Quoting Chris Friedhoff ([EMAIL PROTECTED]): >> Hello, >> >> in updating the documentation >> http://www.friedhoff.org/posixfilecaps.html I discovered that it is >> possible to give directories through setcap also the extende

[PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom check

2007-12-26 Thread Serge E. Hallyn
Hi Andrew Morgan, does this patch look reasonable to you? thanks, -serge >From ed2e7764917fd56d9743630bd7072f67ff30adc2 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] <[EMAIL PROTECTED](none)> Date: Wed, 26 Dec 2007 15:04:50 -0800 Subject: [PATCH 1/1] capabilities: oom_kill: don't set PF_SUPER

Re: [PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom check

2007-12-26 Thread Andrew Morgan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This looks fine. Thanks! Acked-by: Andrew G. Morgan <[EMAIL PROTECTED]> Serge E. Hallyn wrote: > Hi Andrew Morgan, > > does this patch look reasonable to you? > > thanks, > -serge > >>From ed2e7764917fd56d9743630bd7072f67ff30adc2 Mon Sep 17 00:00

[PATCH] Exporting capability code/name pairs

2007-12-26 Thread KaiGai Kohei
This patch enables to export the code/name pairs of capabilities under /capability of securityfs. In the current libcap, it obtains the list of capabilities from header file on the build environment statically. However, it is not enough portable between different versions of kernels, because an al