From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org, chrisw@sous-sol.org
Subject: Re: [RFC] [PATCH] file posix capabilities
Date: Mon, 14 Aug 2006 21:29:53 -0600 [thread overview]
Message-ID: <m13bbyr80e.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060815020647.GB16220@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Mon, 14 Aug 2006 21:06:47 -0500")
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> In fact my version knowingly ignores CAP_AUDIT_WRITE and
> CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
> So a version number may make sense.
>
>> So we need some for of
>> forward/backward compatibility. Maybe in the cap name?
>
> You mean as in use 'security.capability_v32" for the xattr name?
> Or do you really mean add a cap name to the structure?
I was thinking the xattr name. But mostly I was looking
for a place where you had possibly stashed a version.
Thinking about it possibly the most portable thing to do
is to assign each cap a well known name. Say
"security.cap.dac_override" and have a value in there like +1
add the cap -1 clear the cap. That at least seems to provide
granularity and some measure of future proofing and some measure of
portability. The space it would take with those names looks ugly
though.
The practical question is what do you do with a program that
was give a set of capabilities you no longer support?
Do you run it without any capabilities at all?
Do you give it as many capabilities of what it asked for
as you can?
Do you complain loudly and refuse to execute it at all?
What is the secure choice that least violates the principle of least surprise?
Eric
next prev parent reply other threads:[~2006-08-15 3:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 1:13 [RFC] [PATCH] file posix capabilities Serge E. Hallyn
2006-08-14 22:06 ` Serge E. Hallyn
2006-08-15 0:20 ` Eric W. Biederman
2006-08-15 2:06 ` Serge E. Hallyn
2006-08-15 3:29 ` Eric W. Biederman [this message]
2006-08-15 4:22 ` Nicholas Miell
2006-08-15 11:49 ` Serge E. Hallyn
2006-08-15 12:20 ` Serge E. Hallyn
2006-08-15 19:31 ` Nicholas Miell
2006-08-15 19:41 ` Serge E. Hallyn
2006-08-15 16:18 ` Stephen Smalley
2006-08-15 16:36 ` Casey Schaufler
2006-08-16 2:42 ` Serge E. Hallyn
2006-08-16 13:20 ` Stephen Smalley
2006-08-17 12:00 ` Joshua Brindle
2006-08-17 12:28 ` Stephen Smalley
2006-08-21 20:36 ` Serge E. Hallyn
2006-08-28 21:39 ` Serge E. Hallyn
2006-08-29 18:37 ` Seth Arnold
2006-08-29 19:58 ` Serge E. Hallyn
2006-08-19 2:02 ` Crispin Cowan
2006-08-19 17:08 ` Casey Schaufler
2006-08-22 2:50 ` Serge E. Hallyn
2006-08-22 3:19 ` Seth Arnold
2006-08-19 2:02 ` Crispin Cowan
[not found] ` <44E1153D.9000102@ak.jp.nec.com>
[not found] ` <20060815021612.GC16220@sergelap.austin.ibm.com>
2006-08-15 3:48 ` KaiGai Kohei
2006-08-15 12:04 ` Serge E. Hallyn
2006-08-15 16:02 ` Casey Schaufler
2006-08-16 2:25 ` Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2006-08-16 2:43 Albert Cahalan
2006-08-16 3:23 ` Serge E. Hallyn
2006-08-16 3:44 ` Casey Schaufler
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=m13bbyr80e.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox