ove I'm not sure I like that approach so much,
however, I could be misunderstanding something. Do you have a small example
you could send?
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
e goes so any
comments/feedback on the above proposal are welcome. If it turns out this
approach has some merit I'll put together a patch and send it out.
Once again, sorry for the regression.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
n
Smalley <[EMAIL PROTECTED]>, Paul Moore <[EMAIL PROTECTED]>
On Fri, 13 Jul 2007, Michal Piotrowski wrote:
>
>>
> My system is too secure, I can not login :)
>
>Do you have CONFIG_NETLABEL=y ?
>
>If so, please try disabling it.
Disabling NetLabel shoul
-Original Message-
From: Stephen Smalley <[EMAIL PROTECTED]>
Date: Friday, Jul 13, 2007 3:30 pm
Subject: Re: The art of breaking userspace (was Re: [GIT] SELinux changes
for 2.6.23 (updated))
To: Michal Piotrowski <[EMAIL PROTECTED]>
CC: Paul Moore <[EMAIL PROT
lem that Michal reported.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ABEL
> ..
> #else
> ..
> #endif
>
> which might as well be cleaned up at the same time (and might have avoided
> this bug, since then the people involved would have seen the _correct_
> example in the first version)
Oh my. I'll fix this and get an
locks into a single block to ease future review as recommended by Linus.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
include/net/netlabel.h | 62 -
net/netlabel/netlabel_cipso_v4.c |5 +++
net/netlabel/netlabel_kapi.c | 21 +
ms.
Once again, thank you all for your patience.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the F
Label will not notice any
difference.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
security/selinux/hooks.c| 21 +++--
security/selinux/netlabel.c | 41 -
2 files changed, 31 insertions(+), 31 deletions(-)
Index: linux-2.6_n
we only want to read lock the policy and not write lock the policy -
a spinlock, even a read/write spinlock, seems a bit expensive here.
If we were to convert from a read/write spinlock to a RCU locking mechanism
would this solve the preemption problem (I'm not a lock expert either)?
On Monday 04 June 2007 5:39:00 pm Stephen Smalley wrote:
> On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
> > I'm not an expert on the SELinux security server guts like the other
> > people on the To/CC line of this thread, but here are my two cents on the
> > issu
x next branch after this merge
window.
Miklos, this patchset depends on patches in your overlayfs-next
branch, I assume you're pushing that branch during the upcoming merge
window?
James, assuming the overlayfs-next branch is pulled during the merge
window, can you rebase your linux-security#next branch to v4.8-rc1
once Linus tags it?
--
paul moore
www.paul-moore.com
On Thu, Jul 21, 2016 at 7:09 PM, James Morris wrote:
> On Thu, 21 Jul 2016, Paul Moore wrote:
>> James, assuming the overlayfs-next branch is pulled during the merge
>> window, can you rebase your linux-security#next branch to v4.8-rc1
>> once Linus tags it?
>
> Yep.
O
gt; new_tsec->sid = old_tsec->sid;
> }
>
> - ad.type = LSM_AUDIT_DATA_PATH;
> - ad.u.path = bprm->file->f_path;
> + ad.type = LSM_AUDIT_DATA_FILE;
> + ad.u.file = bprm->file;
>
> if (new_tsec->sid == old_tsec->sid) {
> rc = avc_has_perm(old_tsec->sid, isec->sid,
> @@ -3833,8 +3833,8 @@ static int selinux_kernel_module_from_fi
>
> /* finit_module */
>
> - ad.type = LSM_AUDIT_DATA_PATH;
> - ad.u.path = file->f_path;
> + ad.type = LSM_AUDIT_DATA_FILE;
> + ad.u.file = file;
>
> fsec = file->f_security;
> if (sid != fsec->sid) {
--
paul moore
www.paul-moore.com
On Mon, Sep 19, 2016 at 2:00 PM, Paul Moore wrote:
> On Fri, Sep 9, 2016 at 11:37 AM, Vivek Goyal wrote:
>> Hi,
>>
>> Right now LSM_AUDIT_DATA_PATH type contains "struct path" in union "u" of
>> common_audit_data. This information is used to print p
)
Paul Moore (3):
audit: fix some horrible switch statement style crimes
s390: ensure that syscall arguments are properly masked on s390
audit: fix a double fetch in audit_log_single_execve_arg()
Richard Guy Briggs (2):
audit: fixup: log on errors
On Mon, Aug 29, 2016 at 6:50 PM, Paul Moore wrote:
> On Tue, Aug 23, 2016 at 10:20 AM, Mateusz Guzik wrote:
>> audit_exe_compare directly accesses mm->exe_file without making sure the
>> object is stable. Fixing it using current primitives results in
>> partially duplic
/audit_watch.c | 8 +---
kernel/fork.c| 23 +++
4 files changed, 30 insertions(+), 9 deletions(-)
--
paul moore
security @ redhat
On Mon, Aug 8, 2016 at 8:46 AM, Miklos Szeredi wrote:
> On Fri, Jul 22, 2016 at 5:33 PM, Paul Moore wrote:
>> On Thu, Jul 21, 2016 at 7:09 PM, James Morris wrote:
>>> On Thu, 21 Jul 2016, Paul Moore wrote:
>>>> James, assuming the overlayfs-next branch is pulle
On Thu, Jul 21, 2016 at 5:16 PM, Paul Moore wrote:
> On Wed, Jul 13, 2016 at 10:44 AM, Vivek Goyal wrote:
>> Hi All,
>>
>> Please find attached the V3 of patches. Changes since V2 are as follows.
>>
>> - Fixed the build issue with CONFIG_SECURITY=n.
>>
&g
ive unmount event
kernel/audit_watch.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--
paul moore
www.paul-moore.com
oesn't directly affect my
> work. The primary patch of interest to the audit kernel folks (Paul Moore and
> me) is this patch while the rest of the patchset is interesting, but not
> likely
> to directly affect us. This patch has most of what we need to solve our
> problem.
eturn SECCLASS_UNIX_DGRAM_SOCKET;
> }
> break;
> --
> 2.13.1
--
paul moore
www.paul-moore.com
On Tue, Jun 20, 2017 at 4:04 PM, Stephen Smalley wrote:
> On Tue, 2017-06-20 at 15:49 -0400, Paul Moore wrote:
>> On Mon, Jun 19, 2017 at 5:33 PM, Luis Ressel wrote:
>> > For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
>> > net/unix/af_unix.c). This is a tad o
On Wed, Jun 21, 2017 at 5:48 AM, Luis Ressel wrote:
> On Tue, 20 Jun 2017 17:43:38 -0400
> Paul Moore wrote:
>
>> Considering where we are at with respect to the merge window, let's
>> shelve this for now and I'll merge it after the next merge window
>> close
audit_size = size - 1;
> else
> audit_size = size;
> } else {
> - str = "";
> audit_size = 0;
>
len = 0;
> rc = next_entry(buf, fp, sizeof(u32));
> if (rc)
> return rc;
> --
> 2.14.1
>
--
paul moore
www.paul-moore.com
t; max_chain_len = 0;
> - for (slots_used = max_chain_len = i = 0; i < h->size; i++) {
> + for (i = 0; i < h->size; i++) {
> cur = h->htable[i];
> if (cur) {
> slots_used++;
> --
> 2.14.1
--
paul moore
www.paul-moore.com
questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line.
--
paul moore
www.paul-moore.com
t(ab, " obj=%s", secctx);
> - security_release_secctx(secctx, len);
> - }
> -}
> -EXPORT_SYMBOL(audit_log_secctx);
> -#endif
> -
> EXPORT_SYMBOL(audit_log_start);
> EXPORT_SYMBOL(audit_log_end);
> EXPORT_SYMBOL(audit_log_format);
>
--
paul moore
www.paul-moore.com
me why an incomplete path
>> from some seemingly random place in the filesystem tree is preferable to
>> something that gives it an anchor point, at least to human interpreters.
>
> The path should stay. Just the file system type needs decoupling and moving.
See my previous comments about relative pathnames, specifially the
part about me not being a fan of them in the PATH records.
--
paul moore
www.paul-moore.com
filesystem magic
(2017-11-10 16:08:56 -0500)
audit/stable-4.15 PR 20171113
Casey Schaufler (1):
Audit: remove unused audit_log_secctx function
Paul Moore (5
| 55 ++-
security/selinux/ss/conditional.c | 1 -
security/selinux/ss/hashtab.c | 19 +++---
security/selinux/ss/hashtab.h | 4 +++
security/selinux/ss/services.c| 4 +++
5 files changed, 47 insertions(+), 36 deletions(-)
--
paul moore
www.paul-moore.com
ild system point of view.
Okay, thanks.
Acked-by: Paul Moore
> scripts/selinux/Makefile | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/selinux/Makefile b/scripts/selinux/Makefile
> index e8049da..b3048b8 100644
> --- a/scripts/selinux/Makefile
> +++ b/scripts
limit its scope in an attempt to limit
problems. If a more general solution appears in the future I think we
would make every effect to migrate to that; keeping this initial
effort small should make that easier.
--
paul moore
www.paul-moore.com
that has an unset audit container ID) but provides a blank slate for
the orchestrator(s).
> For nested containers, I actually think the label should be
> hierarchical, so you can add a label for the new nested container but
> it still also contains its parents label as well.
I haven't made up my mind on this completely just yet, but I'm
currently of the mindset that supporting multiple audit container IDs
on a given process is not a good idea.
--
paul moore
www.paul-moore.com
.
In an attempt to stay on-topic, let's try to stick with "audit
container ID" or "container ID" if you must. I really want to avoid
the term "audit namespace" simply because the term "namespace" implies
some things which we aren't planning on doing.
--
paul moore
www.paul-moore.com
;re not reusing either of these?
Ah, granularity arguments, welcome back old friend :)
Once again, we're still trying to sort all this out so I reserve the
right to change my mind, but my current thinking is as follows ...
CAP_AUDIT_WRITE exists to control which applications can submit
userspace generated audit records to the kernel, CAP_AUDIT_CONTROL
exists to control which applications can manage the in-kernel audit
configuration (e.g. filter rules) and the current task's loginuid
value. Reusing CAP_AUDIT_WRITE here would allow any application that
can submit userspace audit records the ability to change the audit
container ID; this would be bad, we don't allow CAP_AUDIT_WRITE to
change the loginuid, it would be even worse to allow it to change the
audit container ID. Reusing CAP_AUDIT_CONTROL is less worse than than
CAP_AUDIT_WRITE, but it gets sticky once we get to the part where we
want to auditd instances in containers, complete with their own
queues, filtering rules, etc.. Perhaps we could use CAP_AUDIT_CONTROL
to guard the audit container ID value, but we would always want to do
that check in the init userns in order to prevent container bound
processes from manipulating their own audit container ID.
--
paul moore
www.paul-moore.com
On Thu, Oct 19, 2017 at 12:25 PM, Eric W. Biederman
wrote:
> Paul Moore writes:
>
>> On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
>> wrote:
>>> Aleksa Sarai writes:
>>>>>> The security implications are that anything that can change the label
t_empty(list)) {
> + list_for_each_entry_rcu(e, list, list) {
> + for (i = 0; i < e->rule.field_count; i++) {
> + struct audit_field *f = &e->rule.fields[i];
> +
> + if (f->type == AUDIT_FSTYPE) {
> + if
> (audit_comparator(parent->i_sb->s_magic,
> + f->op, f->val)) {
> + if (e->rule.action ==
> AUDIT_NEVER) {
> + rcu_read_unlock();
> + return;
> + }
> + }
> + }
> + }
> + }
> + }
> +rcu_read_unlock();
> +
> if (inode)
> handle_one(inode);
>
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
warning when applied on
top of Linus' current ... I'll reapply the patch once I've resolved the issue.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ork_audit")
Hi Stephen,
I apologize for the build warning, for some reason it works just fine
in audit#next but causes problems on top of more current trees. I'm
going to drop the patch until I've resolved the issue.
--
paul moore
www.paul-moore.com
--
To unsubscribe from
On Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez wrote:
> On Wed, Aug 26, 2015 at 10:35:19PM -0400, Paul Moore wrote:
>> On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez wrote:
>> > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
>> > Now let's
that reason.
However, I haven't given any serious thought yet to how we would
structure the new blob format so as to support both signed/unsigned
policies as well as existing policies which predate any PKCS #7
changes.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send
On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
wrote:
>> -Original Message-
>> From: Paul Moore [mailto:p...@paul-moore.com]
>> Sent: Thursday, August 27, 2015 4:57 PM
>> To: Luis R. Rodriguez
>> Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lut
On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez wrote:
> On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
>> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
>> wrote:
>> > Even triggered updates make sense, since you can at least have some form
>
ntry_SYSCALL_64_fastpath+0x12/0x76
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
paul moore
www.paul-moore.co
pr_warn("re-scheduling(#%d) write to
> audit_pid=%d\n",
> + attempts, audit_pid);
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule();
> + __set_current_state(TASK
m. It seems like we should prevent the registration of a new auditd if we
already have an auditd instance connected, although as you say, that isn't the
easiest thing to do.
How painful would it be to return -EAGAIN to the new auditd while sending some
sort of keep-alive/ping/etc. message
(int class, unsigned *list)
> {
> __u32 *p = kcalloc(AUDIT_BITMASK_SIZE, sizeof(__u32), GFP_KERNEL);
> +
> if (!p)
> return -ENOMEM;
Okay.
> while (*list != ~0U) {
> +
> unsigned n = *list++;
> if (n >= AUDIT_BIT
On Sunday, October 18, 2015 12:50:45 PM Scott Matheina wrote:
> On 10/14/2015 04:54 PM, Paul Moore wrote:
> > On Saturday, October 10, 2015 08:57:55 PM Scott Matheina wrote:
> >> Signed-off-by: Scott Matheina
> >> ---
> >>
> >> kernel/auditfilter.
t directly via
stgit/git/whatever; if I have to transform your patch in some way to
get it to apply, I get grumpy, and I don't like to get grumpy.
Beyond that, good luck and have fun :)
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-k
t audit by executable (2015-08-12 22:04:07 -0400)
----
Paul Moore (1):
audit: fix uninitialized variable in audit_add_rule()
Richard Guy Briggs (7):
audit: eliminate unnecessary extra layer of watch references
audit: eliminate u
ASK_INTERRUPTIBLE);
> + schedule();
> + __set_current_state(TASK_RUNNING);
> + goto restart;
See my comment above about the skb's reference count.
> + }
> }
>
still need to do whatever audit records
are required, see below).
Wearing my audit hat, I want to make sure we tick off all the right
boxes for the various certifications that people care about. Steve
Grubb has commented on what he needs in the past, although I'm not
sure it was on-list, so I
On Fri, Oct 23, 2015 at 4:51 PM, Steve Grubb wrote:
> On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote:
>> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook wrote:
>> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski
> wrote:
>> >> I would argue that,
. I also wrote a whole set of patches for libseccomp
to make it easier that never went anywhere -- I should dust those off
and package them into their own library.
It has been a while since we discussed those patches, but if I remember
correctly it was going to be very difficult to do it
n active EPO contition, which
> * locks all radios in one of the BLOCKED states.
> *
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
audit_log_end(ab);
> }
> + audit_log_contid(context, "tty", audit_get_contid(tsk));
> + audit_free_context(context);
> }
--
paul moore
www.paul-moore.com
read it and interpret it as
>> they see fit.
>
> OK, in which case human eyes *need* the name as well as the value.
> That, and strcmp(value, "enforce=0") is no harder than strcmp(value, "0").
The initial use case may not require parsing the string, but who knows
what will end up using this five years from now. Once again, I agree
with Casey, let's make sure it easily parsed and readable by admins;
imagine this as the output of a file under /proc or /sys.
>>> You already have it right for the "hashalg" field. If you want to
>>> be really forward looking you could use names field names that
>>> identify the security module that uses them, such as
>>>
>>> "selinux/enforce=1:selinux/checkreqprot=0:selinux/MD5=8675309"
>> That seems a bit verbose, particularly the duplicated selinux/ bit.
>
> True that, on the other hand
>
> "selinux(enforce=1:checkreqprot=0:MD5=8675309)"
>
> would be harder to parse. Either works for me.
I'm not sure I care too much about how the name-value pairs get
namespaced, but considering the LSM stacking work that is happening,
we should namespace it somehow.
--
paul moore
www.paul-moore.com
h web source in license notices
Paul Moore (2):
selinux: ensure the context is NUL terminated in security_context_to_sid_c
ore()
selinux: skip bounded transition processing if the policy isn't loaded
security/selinux/include/netlabel.h | 3 +--
security/selinux/netlabel.c
_network_audit net = {0,};
>> u32 tsid = task_sid(task);
>>
>> +if (!sksec)
>> +return -EFAULT;
>> if (sksec->sid == SECINITSID_KERNEL)
>> return 0;
>>
>
> This looks sane to me as a simple 4.4-only fix. If the SELinux
> maintainer acks it, I can easily queue this up.
This revision addresses my concerns with Mark's previous patch.
Acked-by: Paul Moore
--
paul moore
www.paul-moore.com
know and
we can work something out.
--
paul moore
www.paul-moore.com
08 3c 03 0f 8e 83 01 00
> 00 41 8b 75 10 31
> RIP [] sock_has_perm+0x1fe/0x3e0
> security/selinux/hooks.c:4069
> RSP
> ---[ end trace 7b5aaf788fef6174 ]---
>
> Signed-off-by: Mark Salyzyn
> Signed-off-by: Paul Moore
No, in the previous thread I gave my ack, not my sign-off; please
On Thu, Feb 1, 2018 at 11:20 AM, Mark Salyzyn wrote:
> On 02/01/2018 08:00 AM, Paul Moore wrote:
>>
>> On Thu, Feb 1, 2018 at 10:37 AM, Mark Salyzyn wrote:
>>>
>>> In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket
>>> flag&quo
, and if the case, reject the permissions.
>
> This adjustment is orthogonal to infrastructure improvements that may
> nullify the needed check, but should be added as good code hygiene.
I'm skeptical that this is the full solution for systems that lack the
SOCK_RCU_FREE protection.
On Fri, Jan 19, 2018 at 10:49 AM, Mark Salyzyn wrote:
> On 01/18/2018 02:36 PM, Paul Moore wrote:
>> On Thu, Jan 18, 2018 at 4:58 PM, Mark Salyzyn wrote:
>>> general protection fault: [#1] PREEMPT SMP KASAN
>>> CPU: 1 PID: 14233 Comm: syz-executor2 Not t
name = kzalloc(sizeof(*name), GFP_NOFS);
> if (!name)
> return;
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
f (!ab)
> - goto out;
> + return;
> audit_log_format(ab, "op=%s", operation);
> audit_log_task_info(ab, current);
> audit_log_format(ab, " res=0");
> audit_log_end(ab);
> -
> - /* Generate AUDIT
dentry, 0);
> audit_log_link_denied("follow_link", &nd->stack[0].link);
> return -EACCES;
> }
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
lready checking audit_dummy_context() above we don't
need to check it again in audit_inode(), you should just call
__audit_inode() directly. As a reminder, make sure you convert
LOOKUP_PARENT to AUDIT_INODE_PARENT.
> + audit_log_link_denied("follow_link");
> + putname(filename);
> +out:
> + kfree(pathname);
> + return;
> +}
--
paul moore
www.paul-moore.com
On Mon, Mar 12, 2018 at 3:59 AM, Richard Guy Briggs wrote:
> On 2018-03-08 19:50, Paul Moore wrote:
...
>> (Point #2 is why I didn't merge patch 3/4, just include it in this
>> revised patch)
>
> On reviewing this, I'm not totally convinced the parent record is
id=root euid=root
>> suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1
>> comm=ls exe=/usr/bin/ls
>
> So, if we now only emit the ANOM_LINK event when audit is enabled, we
> should get rid of all the duplicate information in that record. The
> SYSCALL record has all that information.
As discussed previously, I'm not going to merge any patches which
remove fields from existing records.
--
paul moore
www.paul-moore.com
On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs wrote:
> On 2018-03-12 11:12, Paul Moore wrote:
>> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs wrote:
>> > Audit link denied events for symlinks had duplicate PATH records rather
>> > than just updati
On Mon, Mar 12, 2018 at 11:30 AM, Richard Guy Briggs wrote:
> On 2018-03-12 11:05, Paul Moore wrote:
>> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs wrote:
>> > Audit link denied events generate duplicate PATH records which disagree
>> > in different ways from s
On Mon, Mar 12, 2018 at 11:52 AM, Richard Guy Briggs wrote:
> On 2018-03-12 11:53, Paul Moore wrote:
>> On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs wrote:
>> > On 2018-03-12 11:12, Paul Moore wrote:
>> >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Brigg
On Fri, Sep 8, 2017 at 6:09 PM, James Morris wrote:
> On Fri, 8 Sep 2017, Paul Moore wrote:
>> Looks fine to me from a SELinux perspective. If Casey and John are
>> happy with this I can volunteer to pull it into the selinux/next tree
>> (once the merge window closes), othe
as
> being submitted.
The selinux/next branch is based on v4.16-rc1 and doesn't feed into
the netdev tree, it goes straight to Linus during the merge window so
unfortunately I think we may need to carry this for some time and
relay this fix-up patch up to Linus during the merge window.
--
paul moore
www.paul-moore.com
On Wed, Mar 7, 2018 at 11:41 AM, David Miller wrote:
> From: Paul Moore
> Date: Wed, 7 Mar 2018 11:34:31 -0500
>> On Mon, Mar 5, 2018 at 2:03 AM, Xin Long wrote:
>>> On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell
>>> wrote:
>>>> Hi Paul,
>>
On Wed, Mar 7, 2018 at 12:45 PM, David Miller wrote:
> From: Paul Moore
> Date: Wed, 7 Mar 2018 12:27:52 -0500
>
>> I'm not sure we could have cleanly separated the core network stack
>> changes from the rest of the SELinux/SCTP enablement, regardless it's
>>
On April 8, 2018 2:13:51 AM Xin Long wrote:
On Sat, Apr 7, 2018 at 7:07 AM, Linus Torvalds
wrote:
On Tue, Apr 3, 2018 at 6:37 PM, Paul Moore wrote:
Everything passes the selinux-testsuite, but there are a few known
merge conflicts. The first is with the netdev tree and is in
net/sctp/socket.c
but to
be honest I trust his SCTP understanding much more than mine. I also do weekly
tests of each rcX release at a minimum so if something odd pops up I'll make
sure you get a fix.
Thanks again everyone.
--
paul moore
www.paul-moore.com
re *always* exceptions), and this seems like a reasonable change that
shouldn't negatively affect anyone.
I'll merge this once the merge window comes to a close (we are going
to need to base selinux/next on v4.17-rc1).
> }
>
> length = count;
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
particular case.
Also like the other patch, this will need to wait for the merge window
to close before I can merge it.
> from_kuid(&init_user_ns, audit_get_loginuid(current)),
> audit_get_sessionid(current));
> out:
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
w_bug.cgi?id=1430944
> However, we can't break existing users. Userspace should still attempt to
> proceed
> even if runtime disable fails, just with SELinux left in permissive mode and
> no
> policy loaded. That generally should work, but does retain the performance
> overhead
> of the SELinux hook function processing, unlike a real disable.
>
> I don't think we particularly care about allow_unload_modules /
> allow_unregister_module
> since there is no existing userspace or configurations relying on it.
--
paul moore
www.paul-moore.com
t; - * @link: the path that triggered the restriction
> */
> -void audit_log_link_denied(const char *operation, const struct path *link)
> +void audit_log_link_denied(const char *operation)
> {
> struct audit_buffer *ab;
*sigh*
You forgot to update may_follow_link().
--
paul moore
www.paul-moore.com
n include them in the 0/2 patch as it's probably a bit
much for the individual patches.
> return -EACCES;
> }
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
ecid = cred_sid(cred);
> - return avc_has_perm(secid, task_sid(p), SECCLASS_PROCESS, perm, NULL);
> + return avc_has_perm(&selinux_state,
> + secid, task_sid(p), SECCLASS_PROCESS, perm, NULL);
> }
>
> static void selinux_task_to_inode(struct task_struct *p,
Thanks Stephen, that looks correct to me.
--
paul moore
www.paul-moore.com
nk_denied - report a link restriction denial
> * @operation: specific link operation
> - * @link: the path that triggered the restriction
> */
> -void audit_log_link_denied(const char *operation, const struct path *link)
> +void audit_log_link_denied(const char *operation)
> {
> struct audit_buffer *ab;
>
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
i.c
> +++ b/fs/namei.c
> @@ -945,6 +945,7 @@ static inline int may_follow_link(struct nameidata *nd)
> if (nd->flags & LOOKUP_RCU)
> return -ECHILD;
>
> + audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> audit_log_link_den
On Wed, Mar 7, 2018 at 3:26 PM, David Miller wrote:
> From: Paul Moore
> Date: Wed, 7 Mar 2018 15:20:33 -0500
>
>>> So you would only have to wait until my tree went in before
>>> sending your pull request.
>>
>> So you would want me to rebase selinux/next
7;t something I'm
going to be able to carefully review in the time I've got left today,
so it's going to have to wait until tomorrow and Friday ... however,
speaking on general principle I don't have an objection to the ideas
put forth here.
Andy, if you've got any Reviewed-by/Tested-by/NACK/etc. you want to
add, that would be good to have.
--
paul moore
www.paul-moore.com
On Wed, Mar 7, 2018 at 6:41 PM, Paul Moore wrote:
> On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote:
>> On Wed, 7 Mar 2018, Andy Lutomirski wrote:
>>> Wow, this was a long time ago.
>>
>> Oh yeah; but it now resurfaced on our side, as we are of course recei
d->state >= SCTP_STATE_ESTABLISHED)
> + err = -EISCONN;
> + else
> + err = -EALREADY;
> + goto free;
> }
>
> - /* If the SCTP_INIT ancillary data is specified, set all
> - * the association init values accordingly.
> - */
> - if (sinit) {
> - if (sinit->sinit_num_ostreams) {
> - __u16 outcnt = sinit->sinit_num_ostreams;
> -
> - asoc->c.sinit_num_ostreams = outcnt;
> - /* outcnt has been changed, so re-init stream
> */
> - err = sctp_stream_init(&asoc->stream, outcnt,
> 0,
> - GFP_KERNEL);
> - if (err)
> - goto out_free;
> - }
> - if (sinit->sinit_max_instreams) {
> - asoc->c.sinit_max_instreams =
> - sinit->sinit_max_instreams;
> - }
> - if (sinit->sinit_max_attempts) {
> - asoc->max_init_attempts
> - = sinit->sinit_max_attempts;
> - }
> - if (sinit->sinit_max_init_timeo) {
> - asoc->max_init_timeo =
> -
> msecs_to_jiffies(sinit->sinit_max_init_timeo);
> - }
> + if (sctp_endpoint_is_peeled_off(ep, daddr)) {
> + err = -EADDRNOTAVAIL;
> + goto free;
> }
>
> - /* Prime the peer's transport structures. */
> - transport = sctp_assoc_add_peer(asoc, &to, GFP_KERNEL,
> SCTP_UNKNOWN);
> + transport = sctp_assoc_add_peer(asoc, daddr, GFP_KERNEL,
> + SCTP_UNKNOWN);
> if (!transport) {
> err = -ENOMEM;
> - goto out_free;
> + goto free;
> }
> }
>
--
paul moore
www.paul-moore.com
On Thu, Feb 15, 2018 at 5:51 PM, Paul Moore wrote:
> On Thu, Feb 15, 2018 at 1:16 AM, Kees Cook wrote:
>> On Wed, Feb 14, 2018 at 6:33 PM, Richard Guy Briggs wrote:
>>> On 2018-02-14 09:51, Kees Cook wrote:
>>>> On Wed, Feb 14, 2018 at 8:18 AM, Richard Guy Briggs
sk_info(ab, current);
> audit_log_format(ab, " res=0");
> audit_log_end(ab);
> -
> - /* Generate AUDIT_PATH record with object. */
> - name->type = AUDIT_TYPE_NORMAL;
> - audit_copy_inode(name, link->dentry, d_backing_inode(link->
ei.c
> @@ -945,6 +945,7 @@ static inline int may_follow_link(struct nameidata *nd)
> if (nd->flags & LOOKUP_RCU)
> return -ECHILD;
>
> + audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> audit_log_link_denied("follow_link", &nd-
On Thu, Mar 8, 2018 at 7:30 PM, Paul Moore wrote:
> On Wed, Feb 14, 2018 at 11:18 AM, Richard Guy Briggs wrote:
>> Audit link denied events for symlinks had duplicate PATH records rather
>> than just updating the existing PATH record. Update the symlink's PATH
>> reco
gt; +
> audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> audit_log_link_denied("follow_link", &nd->stack[0].link);
>
> return -EACCES;
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
:56 -0400
>> > > Richard Guy Briggs wrote:
>> > >
>> > > > On 2018-03-12 11:53, Paul Moore wrote:
>> > > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
>> > > > > wrote:
>> > > > > > On 2018-03-12 1
101 - 200 of 1339 matches
Mail list logo
