From: "Bill O'Donnell" <billodo@sgi.com>
To: Chris Friedhoff <chris@friedhoff.org>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>,
KaiGai Kohei <kaigai@kaigai.gr.jp>,
Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH 1/1] security: introduce fs caps
Date: Thu, 9 Nov 2006 08:50:20 -0600 [thread overview]
Message-ID: <20061109145020.GA20535@sgi.com> (raw)
In-Reply-To: <20061109103349.e58e8f51.chris@friedhoff.org>
On Thu, Nov 09, 2006 at 10:33:49AM +0100, Chris Friedhoff wrote:
| Page http://www.friedhoff.org/fscaps.html updated ...
| Kernel 2.6.18.2 updated ...
| System keeps on humming ...
| Is anyone else using/testing the patch? Please give feedback ...
| Thanks ...
I am just starting to test it out. I'll let you know how it goes.
Thanks!
Bill
|
| Chris
|
|
| On Thu, 9 Nov 2006 00:10:21 -0600
| "Serge E. Hallyn" <serue@us.ibm.com> wrote:
|
| > Sorry, I should have noticed and fixed this much sooner. This
| > patch is against the latest full fscaps patch which I'm replying
| > to.
| >
| > From: Serge E. Hallyn <serue@us.ibm.com>
| > Date: Thu, 9 Nov 2006 00:01:49 -0600
| > Subject: security: file caps: fix unused variable warnings
| >
| > Address warnings of unused variables at cap_bprm_set_security
| > when file capabilities are disabled, and simultaneously clean
| > up the code a little, by pulling the new code into a helper
| > function.
| >
| > Rename vfs_cap_data_struct to remove redundant '_struct'.
| >
| > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
| > ---
| > security/commoncap.c | 73 ++++++++++++++++++++++++++++----------------------
| > 1 files changed, 41 insertions(+), 32 deletions(-)
| >
| > diff --git a/security/commoncap.c b/security/commoncap.c
| > index 6f5e46c..4b50b4d 100644
| > --- a/security/commoncap.c
| > +++ b/security/commoncap.c
| > @@ -109,16 +109,17 @@ void cap_capset_set (struct task_struct
| > target->cap_permitted = *permitted;
| > }
| >
| > +#ifdef CONFIG_SECURITY_FS_CAPABILITIES
| > #define XATTR_CAPS_SUFFIX "capability"
| > #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
| > -struct vfs_cap_data_struct {
| > +struct vfs_cap_data {
| > __u32 version;
| > __u32 effective;
| > __u32 permitted;
| > __u32 inheritable;
| > };
| >
| > -static inline void convert_to_le(struct vfs_cap_data_struct *cap)
| > +static inline void convert_to_le(struct vfs_cap_data *cap)
| > {
| > cap->version = le32_to_cpu(cap->version);
| > cap->effective = le32_to_cpu(cap->effective);
| > @@ -126,7 +127,7 @@ static inline void convert_to_le(struct
| > cap->inheritable = le32_to_cpu(cap->inheritable);
| > }
| >
| > -static int check_cap_sanity(struct vfs_cap_data_struct *cap)
| > +static int check_cap_sanity(struct vfs_cap_data *cap)
| > {
| > int i;
| >
| > @@ -149,39 +150,14 @@ static int check_cap_sanity(struct vfs_c
| > return 0;
| > }
| >
| > -int cap_bprm_set_security (struct linux_binprm *bprm)
| > +/* Locate any VFS capabilities: */
| > +static int set_file_caps(struct linux_binprm *bprm)
| > {
| > struct dentry *dentry;
| > ssize_t rc;
| > - struct vfs_cap_data_struct cap_struct;
| > + struct vfs_cap_data cap_struct;
| > struct inode *inode;
| >
| > - /* Copied from fs/exec.c:prepare_binprm. */
| > -
| > - cap_clear (bprm->cap_inheritable);
| > - cap_clear (bprm->cap_permitted);
| > - cap_clear (bprm->cap_effective);
| > -
| > - /* To support inheritance of root-permissions and suid-root
| > - * executables under compatibility mode, we raise all three
| > - * capability sets for the file.
| > - *
| > - * If only the real uid is 0, we only raise the inheritable
| > - * and permitted sets of the executable file.
| > - */
| > -
| > - if (!issecure (SECURE_NOROOT)) {
| > - if (bprm->e_uid == 0 || current->uid == 0) {
| > - cap_set_full (bprm->cap_inheritable);
| > - cap_set_full (bprm->cap_permitted);
| > - }
| > - if (bprm->e_uid == 0)
| > - cap_set_full (bprm->cap_effective);
| > - }
| > -
| > -#ifdef CONFIG_SECURITY_FS_CAPABILITIES
| > - /* Locate any VFS capabilities: */
| > -
| > dentry = dget(bprm->file->f_dentry);
| > inode = dentry->d_inode;
| > if (!inode->i_op || !inode->i_op->getxattr) {
| > @@ -216,9 +192,42 @@ #ifdef CONFIG_SECURITY_FS_CAPABILITIES
| > bprm->cap_permitted = cap_struct.permitted;
| > bprm->cap_inheritable = cap_struct.inheritable;
| >
| > -#endif
| > return 0;
| > }
| > +#else
| > +static int set_file_caps(struct linux_binprm *bprm)
| > +{
| > + return 0;
| > +}
| > +#endif
| > +
| > +int cap_bprm_set_security (struct linux_binprm *bprm)
| > +{
| > + /* Copied from fs/exec.c:prepare_binprm. */
| > +
| > + cap_clear (bprm->cap_inheritable);
| > + cap_clear (bprm->cap_permitted);
| > + cap_clear (bprm->cap_effective);
| > +
| > + /* To support inheritance of root-permissions and suid-root
| > + * executables under compatibility mode, we raise all three
| > + * capability sets for the file.
| > + *
| > + * If only the real uid is 0, we only raise the inheritable
| > + * and permitted sets of the executable file.
| > + */
| > +
| > + if (!issecure (SECURE_NOROOT)) {
| > + if (bprm->e_uid == 0 || current->uid == 0) {
| > + cap_set_full (bprm->cap_inheritable);
| > + cap_set_full (bprm->cap_permitted);
| > + }
| > + if (bprm->e_uid == 0)
| > + cap_set_full (bprm->cap_effective);
| > + }
| > +
| > + return set_file_caps(bprm);
| > +}
| >
| > void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
| > {
| > --
| > 1.4.1
| >
|
|
| --------------------
| Chris Friedhoff
| chris@friedhoff.org
| -
| To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Bill O'Donnell
SGI
651.683.3079
billodo@sgi.com
next prev parent reply other threads:[~2006-11-09 14:47 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-08 22:24 [PATCH 1/1] security: introduce fs caps Serge E. Hallyn
2006-11-08 22:48 ` Alexey Dobriyan
2006-11-08 23:52 ` Serge E. Hallyn
2006-11-09 5:27 ` Alexey Dobriyan
2006-11-09 6:17 ` Serge E. Hallyn
2006-11-13 16:43 ` Serge E. Hallyn
2006-11-13 21:04 ` Alexey Dobriyan
2006-11-14 3:01 ` Serge E. Hallyn
2006-11-09 6:10 ` Serge E. Hallyn
2006-11-09 9:33 ` Chris Friedhoff
2006-11-09 14:50 ` Bill O'Donnell [this message]
2006-11-13 21:57 ` Bill O'Donnell
2006-11-14 5:25 ` Serge E. Hallyn
2006-11-14 13:55 ` Bill O'Donnell
2006-11-14 15:23 ` Serge E. Hallyn
2006-11-14 17:28 ` Chris Friedhoff
2006-11-14 17:40 ` Bill O'Donnell
2006-11-15 12:08 ` KaiGai Kohei
2006-11-15 17:06 ` Bill O'Donnell
2006-11-15 21:49 ` Chris Friedhoff
2006-11-16 14:47 ` Bill O'Donnell
2006-11-17 18:37 ` Chris Friedhoff
2006-11-17 19:12 ` Chris Friedhoff
-- strict thread matches above, loose matches on Subject: below --
2006-11-03 16:57 chris friedhoff
2006-11-03 20:00 ` Serge E. Hallyn
2006-11-03 20:29 ` Stephen Smalley
2006-11-03 20:47 ` Serge E. Hallyn
2006-11-04 2:08 ` Kyle Moffett
2006-11-04 4:12 ` James Morris
2006-11-06 13:31 ` Stephen Smalley
2006-09-06 18:27 Serge E. Hallyn
2006-09-06 20:51 ` Paul Jackson
2006-09-07 1:25 ` Serge E. Hallyn
2006-09-07 6:40 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061109145020.GA20535@sgi.com \
--to=billodo@sgi.com \
--cc=adobriyan@gmail.com \
--cc=akpm@osdl.org \
--cc=chris@friedhoff.org \
--cc=chrisw@sous-sol.org \
--cc=jmorris@namei.org \
--cc=kaigai@kaigai.gr.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.