(it's not affected by LSM hook requirements
> and can be merged separately).
>
> ---
>
> James Morris (2):
> security: introduce CONFIG_SECURITY_WRITABLE_HOOKS
> security: mark LSM hooks as __ro_after_init
Please consider t
m->cred, not current->cred.
One would wonder if we need a security_commit_creds() LSM hook and to
move the existing checks in commit_creds() into commoncaps.c, which
would allow expanding the logic to all LSMs. Currently this doesn't
seem needed, though.
Signed-off-by: Kees Cook
---
fs/e
ily, as with dumpability, this is all masked by commit_creds()
which performs old/new euid and egid tests and clears pdeath_signal.
And again, like dumpability, we should include LSM secureexec logic for
pdeath_signal clearing. For example, Smack goes out of its way to clear
pdeath_signal when it finds a
As discussed with Linus and Andy, we need to reset the stack rlimit
before we do memory layouts when execing a privilege-gaining (e.g.
setuid) program. This moves security_bprm_secureexec() earlier (with
required changes), and then lowers the stack limit when appropriate.
As a side-effect, dumpabi
For a secureexec, before memory layout selection has happened, reset the
stack rlimit to something sane to avoid the caller having control over
the resulting layouts.
$ ulimit -s
8192
$ ulimit -s unlimited
$ /bin/sh -c 'ulimit -s'
unlimited
$ sudo /bin/sh -c 'ulimit -s'
8192
This removes the redundant pdeath_signal clearing in Smack: the check in
smack_bprm_committing_creds() matches the check in smack_bprm_secureexec(),
and since secureexec is now being checked for clearing pdeath_signal, this
is redundant to the common exec code.
Signed-off-by: Kees Cook
Instead of an additional secureexec check for pdeath_signal, just move it
up into the initial secureexec test. Neither perf nor arch code touches
pdeath_signal, so the relocation shouldn't change anything.
Signed-off-by: Kees Cook
---
fs/exec.c | 7 +++
1 file changed, 3 insertions(
cureexec() hook is saved in a new bprm field
"secureexec" so it can be queried later (just AT_SECURE currently).
Signed-off-by: Kees Cook
---
fs/binfmt_elf.c| 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/exec.c | 5 +
include/linux/binfmts.h| 3
Since it's already valid to set dumpability in the early part of
setup_new_exec(), we can consolidate the logic into a single place.
The BINPRM_FLAGS_ENFORCE_NONDUMP is set during would_dump() calls
before setup_new_exec(), so its test is safe to move as well.
Signed-off-by: Kees Cook
--
similar (and correct) comment, so remove the bogus comment
where installation is not actually happening.
Signed-off-by: Kees Cook
---
fs/exec.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 904199086490..7842ae661e34 100644
current (since the mm has
>> + * been replaced).
>> + */
>> + bprm->mm = NULL;
>>
>> set_fs(USER_DS);
>> current->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD |
>
> Eric
--
Kees Cook
Pixel Security
On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> There are several places where exec needs to know if a privilege-gain has
>> happened. These should be using the results of security_bprm_secureexec()
>> but it is getting (needlessly) cal
On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
>> wrote:
>>> Kees Cook writes:
>>>
>>>> There are several places where exec needs to know if a privilege-g
On Mon, Jul 10, 2017 at 7:07 PM, Kees Cook wrote:
> On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
> wrote:
>> Kees Cook writes:
>>
>>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
>>> wrote:
>>>> Kees Cook writes:
>>>>
On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar wrote:
> On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
>> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez wrote:
>> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> >> > > eBPF/seccomp
>>
ntly if needed.
> enum security_filecheck {
> SECURITY_FILECHECK_UNSPEC,
> SECURITY_FILECHECK_MODULE,
> SECURITY_FILECHECK_SYSDATA,
> SECURITY_FILECHECK_KEXEC_KERNEL,
> SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
>
> Provided the MOK thin
[removed bounced email addresses]
On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez wrote:
> On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
>> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez wrote:
>> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote
> obvious. I worry swapping it around with the LSM hook being added
> first makes it significantly less obvious, as (at least for me) the
> security_task_* functions get indirect and difficult to follow quickly
> ("wait, why are we checking SETSCHED for nice?").
>
> A side curi
YS_NICE check in the timerslack_ns_write/show
> functions, as hiding it in the LSM hook seems too opaque, and doesn't
> seem like a widely enough adopted practice.
Yeah, I think this does make it more readable in the end.
>
> Don't really know what I'm doing here, so close r
r/pull/708
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
se
> may be) as before.
>
> The proposed S.A.R.A security module is dependent on
> the mechanism to create its own attr subdirectory.
>
> The original implementation is by Kees Cook.
>
> Signed-off-by: Casey Schaufler
> ---
> Documentation/admin-guide/LSM/index.rst | 13 +++-
e. what is pinning the cred?) I would expect
get_cred()/put_cred() since this is not for "current"? And then what
controls the skp lifetime?
Everything else looks to be mechanical replacement, so that's fine.
Did you use some tooling to do the mechanical replacement or was it
done
t;security/selinux_cred($identifier)/
s/current_security()/selinux_cred(current_cred())/
Is that right? The one __task_cred() use seemed to be fully contained
under rcu read lock.
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing lis
*cred)
> */
> static int tomoyo_bprm_set_creds(struct linux_binprm *bprm)
> {
> + struct tomoyo_domain_info **blob;
> + struct tomoyo_domain_info *domain;
> +
> /*
> * Do only if this function is called for the first time of an execve
>
quot;);
+
security_initcall(tomoyo_init);
(I prefer LSMs do enablement with module params so that they leave
their namespace open for other runtime configuration. I think
"apparmor=" and "selinux=" for enable/disable isn't good to
replicate.)
We will quickly encounter &q
On Tue, Sep 11, 2018 at 9:42 AM, Casey Schaufler wrote:
> Don't use the inode->i_security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Happily mechanical! :)
Reviewed-by: Kees Cook
-Kees
On Tue, Sep 11, 2018 at 9:41 AM, Casey Schaufler wrote:
> Don't use the file->f_security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Seems delightfully mechanical.
Reviewed-by: Kees Cook
-Kees
k_known **blob;
> struct smack_known *skp;
> struct smack_known *tkp = smk_of_task(smack_cred(tsk->cred));
> struct file *file;
> @@ -1842,7 +1833,8 @@ static int smack_file_send_sigiotask(struct task_struct
> *tsk,
> file = container_of(fown, struct file, f_
> - struct inode_smack *issp = smack_inode(inode);
> -
> - /*
> -* The inode may still be referenced in a path walk and
> -* a call to smack_inode_permission() can be made
> -* after smack_inode_free_security() is called.
> -* To a
On Tue, Sep 11, 2018 at 9:42 AM, Casey Schaufler wrote:
> Don't use the inode->i_security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees
On Thu, Sep 13, 2018 at 6:16 AM, Paul Moore wrote:
> On Thu, Sep 13, 2018 at 12:19 AM Kees Cook wrote:
>> On Tue, Sep 11, 2018 at 9:42 AM, Casey Schaufler
>> wrote:
>> > Two proposed security modules require the ability to
>> > share security blobs with
rned, I
> remain unconvinced this is any worse than any other significant
> feature that is a build time option.
That's fine. That's just a code style issue. What I'm trying to show
is that by lifting the allocation logic up out of the LSMs, we've
actually simplified the
On Thu, Sep 13, 2018 at 12:01 PM, Casey Schaufler
wrote:
> On 9/12/2018 4:53 PM, Kees Cook wrote:
>> On Tue, Sep 11, 2018 at 9:41 AM, Casey Schaufler
>> wrote:
>>> Move management of the cred security blob out of the
>>> security modules and into the securi
On Thu, Sep 13, 2018 at 2:51 PM, Kees Cook wrote:
> At the very least, to avoid stacking now (i.e. TOMOYO being enabled
> with another major LSM), we just do nothing. The existing code already
> makes the existing major LSMs exclusive. Adding a stackable LSM would
> need to just
ot;is
stacking allowed?" flag or have new "depends on SECURITY_STACKING". (I
think the CONFIG will force distros into enabling it without any
runtime opt-out.)
> (see my earlier
> comments about the difficulty in determining the source of a failed
> operation).
Agreed. I would hope t
On Thu, Sep 13, 2018 at 4:32 PM, John Johansen
wrote:
> On 09/13/2018 04:06 PM, Kees Cook wrote:
>> - what order should any stacking happen? Makefile? security=?
>>
> Preferably not. For the single LSM we have the ability to choose the default
> LSM, ideally we let the
On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler wrote:
> On 9/13/2018 4:06 PM, Kees Cook wrote:
>> - what order should any stacking happen? Makefile? security=?
> Makefile by default.
Okay, if ordering is by Makefile and everyone dislikes my
$lsm.enabled=0/1 thing, then these m
On Thu, Sep 13, 2018 at 5:08 PM, Casey Schaufler wrote:
> On 9/13/2018 4:57 PM, Kees Cook wrote:
>> On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler
>> wrote:
>>> On 9/13/2018 4:06 PM, Kees Cook wrote:
>>>> - what order should any stacking happen? Makefile
On Thu, Sep 13, 2018 at 5:03 PM, Casey Schaufler wrote:
> On 9/13/2018 4:51 PM, Kees Cook wrote:
>> So, before we can really make a decision, I think we have to decide:
>> should ordering be arbitrary for even this level of stacking?
>
> Do we have a case where it matters
On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler wrote:
> On 9/13/2018 4:06 PM, Kees Cook wrote:
>> If security= is
>> specified, all other major LSMs are disabled (i.e. it is not possible
>> to switch between SELinux/AppArmor/SMACK without also disabling
>> TOMOYO).
On Fri, Sep 14, 2018 at 8:57 AM, Casey Schaufler wrote:
> On 9/13/2018 5:19 PM, Kees Cook wrote:
>> We already have the minor LSMs that cannot change order.
>
> Are you saying that we don't have a mechanism to change
> the order, or that they wouldn't work right
ialized\n");
> - cred->security = &tomoyo_kernel_domain;
> + blob = tomoyo_cred(cred);
> + *blob = &tomoyo_kernel_domain;
> tomoyo_mm_init();
> return 0;
> }
This is missing "tomoyo_enabled =
mack_cred(const struct
> cred *cred)
> return cred->security;
> }
>
> +static inline struct smack_known **smack_file(const struct file *file)
> +{
> + return file->f_security;
> +}
> +
This (and related) still needs splitting out into it's own ref
to mention it is changing the only task
blob user, AppArmor, or split that out into a separate patch.)
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
stead
> of allocating the blobs from within the modules the modules
> tell the infrastructure how much space is required, and
> the space is allocated there.
Maybe split this up too? (SELinux and Smack need tweaks?)
-Kees
--
Kees Cook
Pixel Security
_
tatic inline struct tomoyo_domain_info *tomoyo_domain(void)
> {
> - struct tomoyo_domain_info **blob = tomoyo_cred(current_cred());
> + const struct cred *cred = current_cred();
> + struct tomoyo_domain_info **blob;
> +
> + if (cred->security == NULL)
> +
On Fri, Sep 21, 2018 at 5:17 PM, Casey Schaufler wrote:
> There are no longer users of selinux_is_enabled().
> Remove it. As selinux_is_enabled() is the only reason
> for include/linux/selinux.h remove that as well.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
nux specific code has
> to go. The poisioning could be introduced into the infrastructure
> at some later date.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
> ---
> kernel/cred.c| 13 -
> security/selinux/hooks.c | 6 --
On Fri, Sep 21, 2018 at 5:17 PM, Casey Schaufler wrote:
> Don't use the cred->security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees
On Fri, Sep 21, 2018 at 5:17 PM, Casey Schaufler wrote:
> Don't use the cred->security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees
the modules if it's not already there
> + */
> +void lsm_early_inode(struct inode *inode)
> +{
> + int rc;
> +
> + if (inode == NULL)
> + panic("%s: NULL inode.\n", __func__);
> + if (inode->i_security != NULL)
> +
ce they require.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email contain
ucture how much
> space is required, and the space is allocated there.
> The only user of this blob is AppArmor. The AppArmor use
> is abstracted to avoid future conflict.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
lating the sizes, etc:
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
On Fri, Sep 21, 2018 at 5:18 PM, Casey Schaufler wrote:
> Don't use the cred->security pointer directly.
> Provide helper functions that provide the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees
modules
> tell the infrastructure how much space is required, and
> the space is allocated there.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
On Fri, Sep 21, 2018 at 5:19 PM, Casey Schaufler wrote:
> Don't use the ipc->security pointer directly.
> Don't use the msg_msg->security pointer directly.
> Provide helper functions that provides the security blob pointers.
>
> Signed-off-by: Casey Schaufler
On Fri, Sep 21, 2018 at 5:18 PM, Casey Schaufler wrote:
> Don't use the file->f_security pointer directly.
> Provide a helper function that provides the security blob pointer.
>
> Signed-off-by: Casey Schaufler
Reviewed-by: Kees Cook
-Kees
--
Kees
On Fri, Sep 21, 2018 at 5:19 PM, Casey Schaufler wrote:
> Don't use the ipc->security pointer directly.
> Don't use the msg_msg->security pointer directly.
> Provide helper functions that provides the security blob pointers.
>
> Signed-off-by: Casey Schaufler
On Fri, Sep 21, 2018 at 4:59 PM, Casey Schaufler wrote:
> v4: Finer granularity in the patches and other
> cleanups suggested by Kees Cook.
> Removed dead code created by the removal of SELinux
> credential blob poisoning.
Thanks for the splitting, this really does make
On Sat, Sep 22, 2018 at 9:38 AM, Casey Schaufler wrote:
> On 9/21/2018 8:02 PM, Kees Cook wrote:
>> On Fri, Sep 21, 2018 at 4:59 PM, Casey Schaufler
>> wrote:
>>> v4: Finer granularity in the patches and other
>>> cleanups suggested by Kees Cook.
>>
n Smalley
Cc: Casey Schaufler
Cc: Tetsuo Handa
Cc: Mimi Zohar
Cc: linux-security-mod...@vger.kernel.org
Cc: selinux@tycho.nsa.gov
Signed-off-by: Kees Cook
---
include/linux/lsm_hooks.h | 6 --
security/apparmor/lsm.c| 4 +++-
security/integrity/iint.c | 4 +++-
security/selinux/hooks.c
y: Casey Schaufler
Reviewed-by: Kees Cook
This looks like it should get folded into "LSM: Infrastructure
management of the file security".
-Kees
> ---
> security/security.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/securi
/kernel/git/kees/linux.git/log/?h=lsm/blob-sharing-v4.1
I'm going to work on a merged series for the "arbitrary ordering" and
"blob-sharing" trees next...
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@ty
all LSMs. It's called "legacy"
> since the distinction of "major" will go away in the blob-sharing world.
>
> Signed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
> Reviewed-by: John Johansen
> ---
> include/linux/lsm_hooks.h | 3 +++
>
On Tue, Dec 11, 2018 at 10:57 AM James Morris wrote:
>
> On Tue, 4 Dec 2018, Kees Cook wrote:
>
> > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler
> > wrote:
> > > v5: Include Kees Cook's rework of the lsm command
> > > line interface. Stackin
On Tue, Dec 11, 2018 at 1:19 PM Kees Cook wrote:
>
> On Tue, Dec 11, 2018 at 10:57 AM James Morris wrote:
> >
> > On Tue, 4 Dec 2018, Kees Cook wrote:
> >
> > > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler
> > > wrote:
> > >
On Tue, Jan 8, 2019 at 1:37 PM Casey Schaufler wrote:
>
> On 1/8/2019 1:05 PM, James Morris wrote:
> > On Mon, 7 Jan 2019, Kees Cook wrote:
> >
> >> On Tue, Dec 11, 2018 at 1:19 PM Kees Cook wrote:
> >>> On Tue, Dec 11, 2018 at 10:57 AM James Morris wrot
additional modules (e.g. Landlock, S.A.R.A.) from a
> significant distribution (e.g. Fedora, Ubuntu, SuSE) and ACKs from the
> maintainers of the existing modules we should be able to breeze right in.
>
> Yeah, I think that's about all it would take.
I would strongly recommend Landlock and SARA for every distro. They're
opt-in, and provide much-needed missing userspace defenses (and attack
surface reduction).
-Kees
--
Kees Cook
Pixel Security
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
69 matches
Mail list logo