On Fri 2015-02-27 12:56:41, Andy Lutomirski wrote:
> On Fri, Feb 27, 2015 at 12:48 PM, Pavel Machek wrote:
> > On Fri 2015-02-27 12:15:15, Andy Lutomirski wrote:
> >> On Thu, Feb 26, 2015 at 4:27 AM, Pavel Machek wrote:
> >> > On Wed 2015-02-25 17:59:04, Christoph Lameter wrote:
> >> >> On Wed, 2
On Fri, Feb 27, 2015 at 12:48 PM, Pavel Machek wrote:
> On Fri 2015-02-27 12:15:15, Andy Lutomirski wrote:
>> On Thu, Feb 26, 2015 at 4:27 AM, Pavel Machek wrote:
>> > On Wed 2015-02-25 17:59:04, Christoph Lameter wrote:
>> >> On Wed, 25 Feb 2015, Pavel Machek wrote:
>> >>
>> >> > One solution is
On Fri 2015-02-27 12:15:15, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 4:27 AM, Pavel Machek wrote:
> > On Wed 2015-02-25 17:59:04, Christoph Lameter wrote:
> >> On Wed, 25 Feb 2015, Pavel Machek wrote:
> >>
> >> > One solution is to put capabilities into the elf executable. I believe
> >> >
On Thu, Feb 26, 2015 at 4:27 AM, Pavel Machek wrote:
> On Wed 2015-02-25 17:59:04, Christoph Lameter wrote:
>> On Wed, 25 Feb 2015, Pavel Machek wrote:
>>
>> > One solution is to put capabilities into the elf executable. I believe
>> > there was patch for that. That means you don't need to add cap
On Wed 2015-02-25 17:59:04, Christoph Lameter wrote:
> On Wed, 25 Feb 2015, Pavel Machek wrote:
>
> > One solution is to put capabilities into the elf executable. I believe
> > there was patch for that. That means you don't need to add capability
> > support into filesystems...
>
> Ummm... So I c
On Wed, 25 Feb 2015, Pavel Machek wrote:
> One solution is to put capabilities into the elf executable. I believe
> there was patch for that. That means you don't need to add capability
> support into filesystems...
Ummm... So I can just get any caps by modifying the ELF header?
Looking at the do
On Mon 2015-02-02 18:08:06, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
> > I'm game to participate in such an effort. The POSIX scheme
> > is workable, but given that it's 20 years old and hasn't
> > developed real traction it's hard to call it successful.
>
> Over the
Hi!
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed. As you say below basically
> > anything can be executed by the program so that is completely violated.
>
> Well this patch does not change that. Its just that the fil
Quoting Serge E. Hallyn (se...@hallyn.com):
> Quoting Andrew G. Morgan (mor...@kernel.org):
> > I'm not generally in favor of this. Mostly because this seems to be a
> > mini-root kind of inheritance that propagates privilege to binaries
> > that aren't prepared for privilege.
>
> Earlier in this
Quoting Andrew G. Morgan (mor...@kernel.org):
> I'm not generally in favor of this. Mostly because this seems to be a
> mini-root kind of inheritance that propagates privilege to binaries
> that aren't prepared for privilege.
Earlier in this thread, Casey said:
| One of the holes in the 1003.1e s
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> On 2/2/2015 10:08 AM, Serge Hallyn wrote:
> > Quoting Casey Schaufler (ca...@schaufler-ca.com):
> >> I'm game to participate in such an effort. The POSIX scheme
> >> is workable, but given that it's 20 years old and hasn't
> >> developed real trac
On Wed, 4 Feb 2015, Serge E. Hallyn wrote:
> Ok this is all sounding too magic for my tastes. My original suggestion
> was for an actual new capability set, pA, empty by default. You can
> add bits to it using prctl if ns_capable(CAP_SETPCAP) and all the new bits are
> in your pE. Once set, the
Ok this is all sounding too magic for my tastes. My original suggestion
was for an actual new capability set, pA, empty by default. You can
add bits to it using prctl if ns_capable(CAP_SETPCAP) and all the new bits are
in your pE. Once set, they stay until they are removed using prctl. At
exec,
If permitted is zero (ie., no file capabilities) then I don't think
this will yield any privilege for such an exec. Perhaps I missed
something prior to being included in the thread, but I was under the
impression that this was a case where it was intended that
capabilities would be inherited..?
If
On Wed, 4 Feb 2015, Andrew G. Morgan wrote:
> I was thinking more like this:
>
> int override = secure(SECURE_AMBIENT_PRIVS) &&
> cap_isclear(caps->inheritable.cap);
Uhh.. Then processes that require other capabilties would not pass
them through anymore to other stuff that they invoke.
Also
On Wed, Feb 4, 2015 at 8:12 AM, Andrew G. Morgan wrote:
> I was thinking more like this:
>
> int override = secure(SECURE_AMBIENT_PRIVS) &&
> cap_isclear(caps->inheritable.cap);
>
> CAP_FOR_EACH_U32(i) {
> __u32 permitted = caps->permitted.cap[i];
> __u32 inheritable = over
On Feb 4, 2015 7:56 AM, "Serge E. Hallyn" wrote:
>
> Quoting Christoph Lameter (c...@linux.com):
> > On Wed, 4 Feb 2015, Andrew G. Morgan wrote:
> >
> > > I'm not generally in favor of this. Mostly because this seems to be a
> > > mini-root kind of inheritance that propagates privilege to binaries
I was thinking more like this:
int override = secure(SECURE_AMBIENT_PRIVS) &&
cap_isclear(caps->inheritable.cap);
CAP_FOR_EACH_U32(i) {
__u32 permitted = caps->permitted.cap[i];
__u32 inheritable = override ? new->cap_bset.cap[i] :
caps->inheritable.cap[i];
[...]
Chee
Quoting Christoph Lameter (c...@linux.com):
> On Wed, 4 Feb 2015, Andrew G. Morgan wrote:
>
> > I'm not generally in favor of this. Mostly because this seems to be a
> > mini-root kind of inheritance that propagates privilege to binaries
> > that aren't prepared for privilege. I don't really buy t
On Wed, 4 Feb 2015, Andrew G. Morgan wrote:
> I'm not generally in favor of this. Mostly because this seems to be a
> mini-root kind of inheritance that propagates privilege to binaries
> that aren't prepared for privilege. I don't really buy the mmap code
> concern because the model as it stands
I'm not generally in favor of this. Mostly because this seems to be a
mini-root kind of inheritance that propagates privilege to binaries
that aren't prepared for privilege. I don't really buy the mmap code
concern because the model as it stands says that you trust the binary
(and all of the variou
On Wed, 2015-02-04 at 15:41 +0200, Markku Savela wrote:
> On 04/02/15 15:17, Christoph Lameter wrote:
> > On Wed, 4 Feb 2015, Markku Savela wrote:
> >
> >> Just a note... We had inheritable capabilities in the linux of Nokia N9
> >> phone.
> >
> > Could we review the patch please?
>
> Unfortunate
On 04/02/15 15:17, Christoph Lameter wrote:
On Wed, 4 Feb 2015, Markku Savela wrote:
Just a note... We had inheritable capabilities in the linux of Nokia N9 phone.
Could we review the patch please?
Unfortunately, I don't have it and with quick search only found "N9 MER"
kernels, where the
On Wed, 4 Feb 2015, Markku Savela wrote:
> Just a note... We had inheritable capabilities in the linux of Nokia N9 phone.
Could we review the patch please?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
Just a note... We had inheritable capabilities in the linux of Nokia N9
phone.
If a program needed some capabilities, they had to be requested by the
manifest file inside the debian package. Of course, request is only
granted if the package origin had permission to grant them.
--
To unsubs
On Tue, 3 Feb 2015, Andy Lutomirski wrote:
> >> Is there a clear reason why no non-permitted bits can be inheritable?
> >> If not, then I think this should be (ambient & inheritable &
> >> permitted).
> >
> > Inherited caps via ambient are always be permitted. Otherwise the pass
> > through is not
On Tue, Feb 3, 2015 at 3:14 PM, Christoph Lameter wrote:
> On Tue, 3 Feb 2015, Andy Lutomirski wrote:
>
>> > */
>> > new->cap_permitted.cap[i] =
>> > (new->cap_bset.cap[i] & permitted) |
>> > - (new->cap_inheritable.cap
On Tue, 3 Feb 2015, Andy Lutomirski wrote:
> > */
> > new->cap_permitted.cap[i] =
> > (new->cap_bset.cap[i] & permitted) |
> > - (new->cap_inheritable.cap[i] & inheritable);
> > + (new->cap_inherit
On Tue, Feb 3, 2015 at 11:45 AM, Christoph Lameter wrote:
> On Tue, 3 Feb 2015, Casey Schaufler wrote:
>
>> > (I wasn't going to ask bc I assumed not, but heck maybe you're bored
>> > on a desert island or snowed in and just looking for an excuse to hack :)
>>
>> Not at all bored, but I think this
On Tue, 3 Feb 2015, Casey Schaufler wrote:
> > (I wasn't going to ask bc I assumed not, but heck maybe you're bored
> > on a desert island or snowed in and just looking for an excuse to hack :)
>
> Not at all bored, but I think this could be important.
Ok here is a draft of a patch that follows t
On 2/3/2015 9:28 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>> On 2/3/2015 7:51 AM, Serge E. Hallyn wrote:
>>> Quoting Casey Schaufler (ca...@schaufler-ca.com):
On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn
Quoting Christoph Lameter (c...@linux.com):
> On Tue, 3 Feb 2015, Serge E. Hallyn wrote:
>
> > So again I think the pA seems like an elegant way to work around this.
> > I'm interested in other ideas, but I worry about the proc solution Christoph
> > proposed because it would be system- or namespa
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> On 2/3/2015 7:51 AM, Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (ca...@schaufler-ca.com):
> >> On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
> >>> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn
> >>> wrote:
> Quoting Casey Schaufler (
Quoting Christoph Lameter (c...@linux.com):
> On Tue, 3 Feb 2015, Serge E. Hallyn wrote:
>
> > We've currently got two proposals. (Three includig yours; but I explained
> > my
> > problem with yours earlier this morning - do appreciate the proposal and
> > the patch though, really, thanks) It
On Tue, 3 Feb 2015, Serge E. Hallyn wrote:
> So again I think the pA seems like an elegant way to work around this.
> I'm interested in other ideas, but I worry about the proc solution Christoph
> proposed because it would be system- or namespace-wide, rather than
> per-process.
Ok can we have a
On Tue, 3 Feb 2015, Serge E. Hallyn wrote:
> We've currently got two proposals. (Three includig yours; but I explained my
> problem with yours earlier this morning - do appreciate the proposal and
> the patch though, really, thanks) It's worth digging into the details of
> each, but if they en
On 2/3/2015 7:51 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>> On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
>>> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn
>>> wrote:
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> I'm game to participate in such
Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
> On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
> > Quoting Casey Schaufler (ca...@schaufler-ca.com):
> > > I'm game to participate in such an effort. The POSIX scheme
> > > is workable, but given that it's 20 years old and hasn't
> > > devel
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
> > On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn
> > wrote:
> >> Quoting Casey Schaufler (ca...@schaufler-ca.com):
> >>> I'm game to participate in such an effort. The POSIX scheme
> >>> is workable,
Quoting Christoph Lameter (c...@linux.com):
> On Mon, 2 Feb 2015, Serge Hallyn wrote:
>
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed. As you say below basically
> > anything can be executed by the program so that is c
Quoting Andy Lutomirski (l...@amacapital.net):
> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn wrote:
> > Quoting Casey Schaufler (ca...@schaufler-ca.com):
> >> I'm game to participate in such an effort. The POSIX scheme
> >> is workable, but given that it's 20 years old and hasn't
> >> developed
On 2/3/2015 7:17 AM, Christoph Lameter wrote:
> On Mon, 2 Feb 2015, Andy Lutomirski wrote:
>
>> None of this could address the problem here, though: if I hold a
>> capability and I want to pass that capability to an exec'd helper, I
>> shouldn't need the fs's help to do this.
> Amen!
>
That's compl
On Mon, 2 Feb 2015, Serge Hallyn wrote:
> A key concept behind posix capabilities is that the privilege comes from
> both the person and the file being executed. As you say below basically
> anything can be executed by the program so that is completely violated.
Well this patch does not change t
On Mon, 2 Feb 2015, Andy Lutomirski wrote:
> None of this could address the problem here, though: if I hold a
> capability and I want to pass that capability to an exec'd helper, I
> shouldn't need the fs's help to do this.
Amen!
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Mon, 2 Feb 2015, Andy Lutomirski wrote:
> How many of you will be at LSF/MM? This might be a decent topic.
I will be there for the mm portion and can talk about this if you want.
But note my limited knowledge about security issues.
--
To unsubscribe from this list: send the line "unsubscribe
On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn wrote:
>> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>>> I'm game to participate in such an effort. The POSIX scheme
>>> is workable, but given that it's 20 years old and hasn't
>>> developed real t
On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>> I'm game to participate in such an effort. The POSIX scheme
>> is workable, but given that it's 20 years old and hasn't
>> developed real traction it's hard to call it successful.
>
> Over t
On 2/2/2015 11:05 AM, Austin S Hemmelgarn wrote:
> On 2015-02-02 13:47, Mimi Zohar wrote:
>> On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
>>> Quoting Casey Schaufler (ca...@schaufler-ca.com):
I'm game to participate in such an effort. The POSIX scheme
is workable, but given that
On 2015-02-02 13:47, Mimi Zohar wrote:
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
Quoting Casey Schaufler (ca...@schaufler-ca.com):
I'm game to participate in such an effort. The POSIX scheme
is workable, but given that it's 20 years old and hasn't
developed real traction it's hard
On 2/2/2015 10:08 AM, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>> I'm game to participate in such an effort. The POSIX scheme
>> is workable, but given that it's 20 years old and hasn't
>> developed real traction it's hard to call it successful.
> Over the years we've
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
> > I'm game to participate in such an effort. The POSIX scheme
> > is workable, but given that it's 20 years old and hasn't
> > developed real traction it's hard to call it successful.
>
>
Quoting Andy Lutomirski (l...@amacapital.net):
> On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn wrote:
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed. As you say below basically
> > anything can be executed by the program
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> I'm game to participate in such an effort. The POSIX scheme
> is workable, but given that it's 20 years old and hasn't
> developed real traction it's hard to call it successful.
Over the years we've several times discussed possible reasons for th
On 2/2/2015 8:21 AM, Christoph Lameter wrote:
> Linux capabilities suffer from the problem that they are not inheritable
> like regular process characteristics under Unix. This is behavior that
> is counter intuitive to the expected behavior of processes in Unix.
http://wt.tuxomania.net/publicatio
On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn wrote:
> A key concept behind posix capabilities is that the privilege comes from
> both the person and the file being executed. As you say below basically
> anything can be executed by the program so that is completely violated.
>
> Still, it's not th
A key concept behind posix capabilities is that the privilege comes from
both the person and the file being executed. As you say below basically
anything can be executed by the program so that is completely violated.
Still, it's not that different from mmapping some arbitrary code and
jumping int
Linux capabilities suffer from the problem that they are not inheritable
like regular process characteristics under Unix. This is behavior that
is counter intuitive to the expected behavior of processes in Unix.
In particular there has been recently software that controls NICs from user
space and
57 matches
Mail list logo
