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
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, 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. Stacking is
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 +++
> sec
t/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@tycho.nsa.gov
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
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
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.
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 ma
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
Reviewed-
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 Cook
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 Cook
the 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.
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
Reviewed-
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
rly_inode(struct inode *inode)
> +{
> + int rc;
> +
> + if (inode == NULL)
> + panic("%s: NULL inode.\n", __func__);
> + if (inode->i_security != NULL)
> + return;
> + rc = lsm_inode_alloc(inode);
> + if (rc)
> + panic("%s: Early inode alloc failed.\n", __func__);
> +}
I'm still advising against using panic(), but I'll leave it up to James.
For everything else here:
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.
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
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 Cook
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 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:
> 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
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)
> +
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
_
ht want 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.
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 refactor
");
> - cred->security = _kernel_domain;
> + blob = tomoyo_cred(cred);
> + *blob = _kernel_domain;
> tomoyo_mm_init();
> return 0;
> }
This is missing "tomoyo_enabled = true;" which is included in the next
patch but should be h
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 in a diffe
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 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 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 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
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 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
tacking 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 that audit
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 sec
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 logic. The "stacking" part will only become a
distro-choice once they knowi
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
wn *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_owner);
>
> /* we don't log her
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 Cook
Ms 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 "LSM ordering" as an issue, but not in this
case yet:
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
--
* a call to smack_inode_permission() can be made
> -* after smack_inode_free_security() is called.
> -* To avoid race condition free the i_security via RCU
> - * and leave the current inode->i_security pointer intact.
> -* The inode will be freed
)
> */
> 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
urity/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 list
Sel
> 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 +++--
>
at 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 by han
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.
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.
On Mon, Jul 10, 2017 at 7:07 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
> <ebied...@xmission.com> wrote:
>> Kees Cook <keesc...@chromium.org> writes:
>>
>>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W
On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
<ebied...@xmission.com> wrote:
> Kees Cook <keesc...@chromium.org> writes:
>
>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
>> <ebied...@xmission.com> wrote:
>>> Kees Cook <keesc...@chromiu
On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
<ebied...@xmission.com> wrote:
> Kees Cook <keesc...@chromium.org> writes:
>
>> There are several places where exec needs to know if a privilege-gain has
>> happened. These should be using the resul
ry_handler() will kill 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
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 <keesc...@chromium.org>
---
fs/exec.c | 7 +++
1 file c
xec() hook is saved in a new bprm field
"secureexec" so it can be queried later (just AT_SECURE currently).
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
fs/binfmt_elf.c| 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/exec.c | 5 +
include/lin
and correct) comment, so remove the bogus comment
where installation is not actually happening.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
fs/exec.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 904199086490..7842ae6
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
Signed-off-by: Kees
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 <ke
uckily, 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,
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 <keesc...@chr
policy patch (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 these both:
Acked-by: Kees Cook
the LSM hooks, as it makes the needed ABI change more
> 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
> (&
64 matches
Mail list logo
