zero for most signals,
userspace generally ignores it. Indeed, where I have tried it, the
userspace programs appear to be remarkably tolerant of this re-purposing
of the si_errno value.
Signed-off-by: Andrew G. Morgan
---
init/Kconfig| 16
kernel/signal.c | 21
The correct bug reference for this patch is:
https://bugzilla.kernel.org/show_bug.cgi?id=209689
Reviewed-by: Andrew G. Morgan
On Mon, Nov 30, 2020 at 6:58 PM James Morris wrote:
>
> On Sun, 29 Nov 2020, Serge E. Hallyn wrote:
>
> > Hi James,
> >
> > would you mind
Reviewed-by: Andrew G. Morgan
Works for me too.
On Thu, Nov 19, 2020 at 7:20 PM James Morris wrote:
>
> On Tue, 17 Nov 2020, Andrew G. Morgan wrote:
>
> > Signed-off-by: Andrew G. Morgan
>
> This should be Acked-by or Reviewed-by, unless this is your patch, or it
Signed-off-by: Andrew G. Morgan
On Tue, Nov 17, 2020 at 7:09 AM Serge E. Hallyn wrote:
>
> Namespaced file capabilities were introduced in 8db6c34f1dbc .
> When userspace reads an xattr for a namespaced capability, a
> virtualized representation of it is returned if the caller is
Thanks
Acked-By: Andrew G. Morgan
On Sat, May 23, 2015 at 12:45 PM, Serge E. Hallyn wrote:
> On Thu, May 14, 2015 at 11:39:49PM -0700, Andy Lutomirski wrote:
>> Per Andrew Morgan's request, add a securebit to allow admins to
>> disable PR_CAP_AMBIENT_RAISE. This se
On Sat, Mar 14, 2015 at 3:55 PM, Andy Lutomirski wrote:
> It occurs to me that my previous reply was unnecessarily long and
> missed the point. Trying again:
>
> On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan wrote:
>> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrot
On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote:
> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote:
>> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski
>> wrote:
>>> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>>>>
>>&
On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski wrote:
> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>>
>> > It's to preserve the invariant that pA is always a subset of pI.
>>
>> But since a user can always raise a bit in pI if it is pres
> It's to preserve the invariant that pA is always a subset of pI.
But since a user can always raise a bit in pI if it is present in pP,
what does this invariant add to your model other than inconvenience?
>> I'm also unclear how you can turn off this new 'feature' for a process
>> tree? As it is
th an exploitable flaw to create a privilege escalation
for an arbitrary child program. While I understand that everyone
'knows what they are doing' in implementing this change, I'm convinced
that folk that are up to no good also do... Why not provide a lockable
secure bit to selectively d
ue
Cheers
Andrew
On Wed, Feb 4, 2015 at 8:34 AM, Andy Lutomirski wrote:
> 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-&g
gt;inheritable.cap[i];
[...]
Cheers
Andrew
On Wed, Feb 4, 2015 at 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
>> &g
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 Fri, Dec 7, 2012 at 10:39 AM, Andy Lutomirski wrote:
> On Fri, Dec 7, 2012 at 9:07 AM, Andrew G. Morgan wrote:
>> I'm still missing something with the problem definition.
>>
>> So far if I follow the discussion we have determined that inheritance
>> as imple
I'm still missing something with the problem definition.
So far if I follow the discussion we have determined that inheritance
as implemented is OK except for the fact that giving user an
inheritable pI bit which gives them default permission to use all
binaries endowed with the corresponding file
On Sun, Dec 2, 2012 at 3:04 PM, Andy Lutomirski wrote:
> On Sun, Dec 2, 2012 at 2:26 PM, Andrew G. Morgan wrote:
>> On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski wrote:
>>> On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan wrote:
>>>> There is a fairly well wr
On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski wrote:
> On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan wrote:
>> There is a fairly well written paper ;-) explaining how things are
>> supposed to work:
>>
>> http://ols.fedoraproject.org/OLS/Reprints-2008/h
There is a fairly well written paper ;-) explaining how things are
supposed to work:
http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf
The inheritable set is not intended to work the way you seem to want.
Naive inheritance like that is quite explicitly the opposite of what
was d
I like the sentiment but have you considered the implications for a
default system root user trying to set all=eip ? Existing code can do
this because all bits are accessible by default. If you set the
bounding set to something less than ~0, then any code that currently
does this will start to fail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Acked-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Tested-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
Kohei KaiGai wrote:
| [PATCH 2/3] exporting capability name/code pairs
|
| This patch enables to export code/name pairs of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
I've just tried to build this with a separate obj tree: make O=/path.../
~ the build failed as follows:
~ CC security/dummy.o
~ CC security/inode.o
~ CAPSsecurity/cap_names.h
/bin/sh: security/../scripts/mkcapnames.sh: No su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew G. Morgan wrote:
| Serge E. Hallyn wrote:
| |> It all looks good to me.
| |
| |> Since we've confirmed that wireshark uses capabilities it must be using
| |> prctl(PR_SET_KEEPCAPS), so running it might be a good way to verify
-EPERM;
~ 99 }
so my question is, why should one expect this wireshark code to work? It
looks wrong to me.
Thanks
Andrew
|
|> -serge
|
| Thanks
|
| Andrew
~From 006ddf6903983dd596e360ab1ab8e537b29fab46 Mon Sep 17 00:00:00 2001
From: Andrew G. Morgan <[EMAIL PROTECTE
on Sep 17 00:00:00 2001
From: Andrew G. Morgan <[EMAIL PROTECTED]>
Date: Mon, 18 Feb 2008 15:23:28 -0800
Subject: [PATCH] Implement per-process securebits
[This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES
is enabled at configure time.]
Filesystem capability support ma
p->uid == current->uid)
| + if (p->uid == current->uid)
| return 0;
Signed-off-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHuOWf+bHCR3gb8jsRAr5jAKCQ9MTWW9VNKGbbhacygeI6G7kqTACc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
| Andrew, this pretty much was bound to happen... we need to figure out
| what our approach here should be. My preference is still to allow
| signals when p->uid==current->uid so long as !SECURE_NOROOT. Then as
| people start
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Haavard,
It means your application is not capable(sic) of using the upper 32-bits
of the 64-bit capability sets supported by this newer kernel.
You might consider rebuilding the offending application linking it
against a newer version of libcap:
ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
Thanks for trying to accommodate me :-)
Kohei KaiGai wrote:
| In addition, Andrew suggested me to export these translation by symlinks
| to reduce the number of invocation of system call.
Yes, I wanted to make use of readlink() instead of o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ismail Dönmez wrote:
| What I meant to ask was what does "per-process securebits" brings as
extra.
It allows you to create a legacy free process tree. For example, a
chroot, or container (which Serge can obviously explain in more detail),
environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ismail � wrote:
| At Sunday 03 February 2008 around 08:18:12 Andrew Morton wrote:
|> So how do we ever get to the stage where we can recommend that
distributors
|> turn these things on, and have them agree with us?
|
| FWIW with my distributor hat on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| Quoting Andrew G. Morgan ([EMAIL PROTECTED]):
|> -BEGIN PGP SIGNED MESSAGE-
|> Hash: SHA1
|>
|> Here is the patch to add per-process securebits.
|>
|> Its all code that lives inside the capabili
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
| On Fri, 01 Feb 2008 00:11:37 -0800 "Andrew G. Morgan"
<[EMAIL PROTECTED]> wrote:
|
|> [This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES
|> is enabled at configure time.]
|
| Patch
NR7Nz+QIf4=
=0EgW
-END PGP SIGNATURE-
From 0e9d2531f3e6b6d9f4bf7b71f6661844a51eb661 Mon Sep 17 00:00:00 2001
From: Andrew G. Morgan <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 23:08:53 -0800
Subject: [PATCH] Implement per-process securebits
[This patch represents a n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
While this is cute :-), I guess I'm still not all that convinced that
this is needed.
libcap already had some (admittedly not quite working) support for
numeric values of capabilities not currently defined (which I believe is
now fixed in to
34 matches
Mail list logo
