Re: [PATCH 2/2] updated filesystem auditing patches for lspp test kernel

Hard to give this a meaningful review - particularly the first patch, a large part of which seemed to be moving functionality from one file to another. But slowly reading along, at least this smells like an error: Quoting Amy Griffis ([EMAIL PROTECTED]): +/* Initialize a watch entry. */

Re: [redhat-lspp] labeled ipsec auditing

Quoting Joy Latten ([EMAIL PROTECTED]): On Mon, 2006-10-09 at 14:30 -0500, Klaus Weidner wrote: On Mon, Oct 09, 2006 at 03:15:09PM -0400, Paul Moore wrote: Going back to Joy's original mail I think it was the establishing or deleting of an SA with SELinux context that we were

Re: [RFC][PATCH] audit: get inode pathname patch

Quoting Mimi Zohar ([EMAIL PROTECTED]): We are interested in using auditing's context pathname information. Is this the best way of accessing it? Add support for accessing auditing's inode full pathname. Interesting idea. It does seem to do what you need. -serge Signed-off-by: Mimi

Re: auditing file based capabilities

Quoting Steve Grubb ([EMAIL PROTECTED]): Hi, With file based capabilities in recent kernels, I think we need to add those to the path records. An example PATH record: That's a great idea (and would get me to use audit :). node=127.0.0.1 type=PATH msg=audit(1223893548.459:459): item=1

Re: auditing file based capabilities

Quoting Steve Grubb ([EMAIL PROTECTED]): On Monday 13 October 2008 10:04:27 Serge E. Hallyn wrote: Except I think setcap should also be audited, so that if a task receives some inheritable capabilities, you can tell from the logs when that happened and which executable did it. Do you

Re: PATH records show fcaps

Quoting Eric Paris ([EMAIL PROTECTED]): type=SYSCALL msg=audit(1224342849.465:43): arch=c03e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm=ping

Re: PATH records show fcaps

Quoting Eric Paris ([EMAIL PROTECTED]): type=SYSCALL msg=audit(1224342849.465:43): arch=c03e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm=ping

Re: PATH records show fcaps

Quoting Eric Paris ([EMAIL PROTECTED]): On Mon, 2008-10-20 at 11:31 -0500, Serge E. Hallyn wrote: Quoting Eric Paris ([EMAIL PROTECTED]): type=SYSCALL msg=audit(1224342849.465:43): arch=c03e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid

Re: PATH records show fcaps

Quoting Eric Paris ([EMAIL PROTECTED]): On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote: Quoting Eric Paris ([EMAIL PROTECTED]): type=SYSCALL msg=audit(1224342849.465:43): arch=c03e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid

Re: PATH records show fcaps

Quoting Eric Paris ([EMAIL PROTECTED]): On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote: Quoting Eric Paris ([EMAIL PROTECTED]): On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote: Quoting Eric Paris ([EMAIL PROTECTED]): type=SYSCALL msg=audit(1224342849.465:43): arch

Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Paris wrote: Any time fcaps are used to increase a processes pP or pE we will crate a new audit record which contains the entire set of known information about the executable in question,

Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

Quoting Eric Paris ([EMAIL PROTECTED]): On Wed, 2008-10-22 at 21:13 -0700, Andrew G. Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: ... except if (!issecure(SECURE_NOROOT) uid==0) I guess? And then it also might be interesting in the case

Re: [PATCH -v2 4/4] AUDIT: emit new record type showing all capset information

Quoting Eric Paris ([EMAIL PROTECTED]): diff --git a/kernel/capability.c b/kernel/capability.c index 33e51e7..3d7fc70 100644 --- a/kernel/capability.c +++ b/kernel/capability.c @@ -7,6 +7,7 @@ * 30 May 2002: Cleanup, Robert M. Love [EMAIL PROTECTED] */ +#include linux/audit.h

Re: [PATCH -v2 1/4] CAPABILITIES: add cpu endian vfs caps structure

Quoting Eric Paris ([EMAIL PROTECTED]): This patch add a generic cpu endian caps structure and externally available functions which retrieve fcaps information from disk. This information is necessary so fcaps information can be collected and recorded by the audit system. Signed-off-by:

Re: [PATCH -v2 3/4] AUDIT: collect info when execve results in caps in pE

Quoting Eric Paris ([EMAIL PROTECTED]): On Tue, 2008-11-04 at 10:35 -0600, Serge E. Hallyn wrote: Quoting Eric Paris ([EMAIL PROTECTED]): diff --git a/security/commoncap.c b/security/commoncap.c index 8bb95ed..534abb5 100644 --- a/security/commoncap.c +++ b/security/commoncap.c

Re: [PATCH -v3 1/5] Capabilities: document the order of arguments to cap_issubset

Quoting Eric Paris ([EMAIL PROTECTED]): Document the order of arguments for cap_issubset. It's not instantly clear which order the argument should be in. So give an example. Signed-off-by: Eric Paris [EMAIL PROTECTED] Acked-by: Serge Hallyn [EMAIL PROTECTED] Thanks, Eric. -serge ---

Re: Proof of concept patch, add dropping privileges to a non root user

Quoting corentin.labbe (corentin.la...@geomatys.fr): Hello This is a patch that add a -u parameter to auditd. This parameter permit to auditd to drop to an unprivilegied UID after initialization. Any comment will be appreciated. Cordially --- src/auditd.c.orig 2009-10-05

Re: [PATCH RFC 00/48] Add namespace support for audit

Quoting Gao feng (gaof...@cn.fujitsu.com): On 06/07/2013 06:47 AM, Serge Hallyn wrote: Quoting Serge Hallyn (serge.hal...@ubuntu.com): Quoting Gao feng (gaof...@cn.fujitsu.com): On 05/07/2013 10:20 AM, Gao feng wrote: This patchset try to add namespace support for audit. I choose to

Re: [PATCH RFC 00/48] Add namespace support for audit

Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-06-11 at 13:59 +0800, Gao feng wrote: On 06/11/2013 05:24 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 06/07/2013 06:47 AM, Serge Hallyn wrote: Quoting Serge Hallyn (serge.hal...@ubuntu.com): Quoting

Re: [Part1 PATCH 00/22] Add namespace support for audit

Quoting Eric Paris (epa...@redhat.com): On Thu, 2013-06-20 at 11:02 +0800, Gao feng wrote: On 06/20/2013 04:51 AM, Eric Paris wrote: On Wed, 2013-06-19 at 16:49 -0400, Aristeu Rozanski wrote: On Wed, Jun 19, 2013 at 09:53:32AM +0800, Gao feng wrote: This patchset is first part of

Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

Quoting Gao feng (gaof...@cn.fujitsu.com): Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will

Re: [PATCH 18/20] audit: add new message type AUDIT_CREATE_NS

Quoting Gao feng (gaof...@cn.fujitsu.com): Since there is no more place for flags of clone system call. we need to find a way to create audit namespace. this patch add a new type of message AUDIT_CREATE_NS. user space can create new audit namespace through netlink. Right now, The

Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools

Re: [PATCH 16/20] audit: allow GET, SET, USER MSG operations in audit namespace

Quoting Gao feng (gaof...@cn.fujitsu.com): 1, remove the permission check of pid namespace. it's no reason to deny un-init pid namespace to operate audit subsystem. 2, only allow init user namespace and init audit namespace to operate list/add/del rule, tty set, trim, make equiv

Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting

Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao

Re: [PATCH 1/2] namespaces: give each namespace a serial number

Quoting Richard Guy Briggs (r...@redhat.com): Most of this looks reasonable, but I'm curious about something, +/** + * ns_serial - compute a serial number for the namespace + * + * Compute a serial number for the namespace to uniquely identify it in + * audit records. + */ +unsigned int

Re: [PATCH 0/2] namespaces: log namespaces per task

Quoting Richard Guy Briggs (r...@redhat.com): I saw no replies to my questions when I replied a year after Aris' posting, so I don't know if it was ignored or got lost in stale threads: https://www.redhat.com/archives/linux-audit/2013-March/msg00020.html

Re: [PATCH 0/2] namespaces: log namespaces per task

Quoting James Bottomley (james.bottom...@hansenpartnership.com): On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs wrote: Questions: Is there a way to link serial numbers of namespaces involved in migration of a container to another kernel? (I had a brief look at CRIU.) Is there a

Re: [PATCH V5 02/13] namespaces: expose namespace instance serial number in proc_ns_operations

Quoting Richard Guy Briggs (r...@redhat.com): Expose the namespace instance serial number for each namespace type in the proc namespace operations structure to make it available for the proc filesystem. Signed-off-by: Richard Guy Briggs r...@redhat.com Acked-by: Serge Hallyn

Re: [PATCH V5 13/13] Documentation: add a section for /proc/pid/ns/

Quoting Richard Guy Briggs (r...@redhat.com): --- Acked-by: Serge Hallyn serge.hal...@canonical.com (some nitpicking below) Thanks, Richard. IMO this patchset is great at the moment. Now if I checkpoint a container, migrate it to another machine, and restart it there, the serial numbers will

Re: [PATCH V5 08/13] sched: add a macro to ref all CLONE_NEW* flags

Quoting Richard Guy Briggs (r...@redhat.com): --- Acked-by: Serge Hallyn serge.hal...@canonical.com include/uapi/linux/sched.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..5aceba2

Re: [PATCH V5 11/13] audit: emit AUDIT_NS_INFO record with AUDIT_VIRT_CONTROL record

Quoting Richard Guy Briggs (r...@redhat.com): Signed-off-by: Richard Guy Briggs r...@redhat.com --- include/uapi/linux/audit.h |2 ++ kernel/audit.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/uapi/linux/audit.h

Re: [PATCH V5 09/13] fork: audit on creation of new namespace(s)

Quoting Richard Guy Briggs (r...@redhat.com): When clone(2) is called to fork a new process creating one or more namespaces, audit the event to tie the new pid with the namespace IDs. Signed-off-by: Richard Guy Briggs Acked-by: Serge Hallyn serge.hal...@canonical.com --- kernel/fork.c

Re: [PATCH V5 06/13] audit: log creation and deletion of namespace instances

Quoting Richard Guy Briggs (r...@redhat.com): Log the creation and deletion of namespace instances in all 6 types of namespaces. Twelve new audit message types have been introduced: AUDIT_NS_INIT_MNT 1330/* Record mount namespace instance creation */ AUDIT_NS_INIT_UTS 1331

Re: [PATCH V5 01/13] namespaces: assign each namespace instance a serial number

Quoting Richard Guy Briggs (r...@redhat.com): Generate and assign a serial number per namespace instance since boot. Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not

Re: [PATCH V5 05/13] audit: initialize at subsystem time rather than device time

Quoting Richard Guy Briggs (r...@redhat.com): The audit subsystem should be initialized a bit earlier so that it is in place in time for initial namespace serial number logging. --- Acked-by: Serge Hallyn serge.hal...@canonical.com kernel/audit.c |2 +- 1 files changed, 1

Re: [PATCH V5 03/13] namespaces: expose ns_entries

Quoting Richard Guy Briggs (r...@redhat.com): Expose ns_entries so subsystems other than proc can use this set of namespace operations. Signed-off-by: Richard Guy Briggs r...@redhat.com Acked-by: Serge Hallyn serge.hal...@canonical.com --- fs/proc/namespaces.c|2 +-

Re: [PATCH V5 07/13] audit: dump namespace IDs for pid on receipt of AUDIT_NS_INFO

Quoting Richard Guy Briggs (r...@redhat.com): When a task with CAP_AUDIT_CONTROL sends a NETLINK_AUDIT message of type AUDIT_NS_INFO with a PID of interest, dump the namespace IDs of that task to the audit log. --- Acked-by: Serge Hallyn serge.hal...@canonical.com kernel/audit.c | 14

Re: [PATCH V5 13/13] Documentation: add a section for /proc/pid/ns/

Quoting Serge E. Hallyn (se...@hallyn.com): Quoting Richard Guy Briggs (r...@redhat.com): --- Acked-by: Serge Hallyn serge.hal...@canonical.com (some nitpicking below) (As discussed, please ignore the ' nitpicking :) thanks, -serge -- Linux-audit mailing list Linux-audit@redhat.com

Re: [PATCH] capabilities: do not audit log BPRM_FCAPS on set*id

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-04-11 15:36, Paul Moore wrote: > > On Wed, Mar 29, 2017 at 6:29 AM, Richard Guy Briggs wrote: > > > On 2017-03-09 09:34, Steve Grubb wrote: > > >> On Tuesday, March 7, 2017 4:10:49 PM EST Richard Guy Briggs wrote: > > >> > >

Re: [RFC][PATCH] audit: add ambient capabilities to CAPSET and BPRM_FCAPS records

Quoting Richard Guy Briggs (r...@redhat.com): > Capabilities were augmented to include ambient capabilities in v4.3 > commit 58319057b784 ("capabilities: ambient capabilities"). > > Add ambient capabilities to the audit BPRM_FCAPS and CAPSET records. > > The record contains fields "old_pp",

Re: [PATCH] audit: unswing cap_* fields in PATH records

Quoting Richard Guy Briggs (r...@redhat.com): > The cap_* fields swing in and out of PATH records. > If no capabilities are set, the cap_* fields are completely missing and when > one of the cap_fi or cap_fp values is empty, that field is omitted. > > Original: > type=PATH msg=audit(04/20/2017

Re: [PATCH] capabilities: do not audit log BPRM_FCAPS on set*id

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-03-02 21:50, Richard Guy Briggs wrote: > > On 2017-03-02 20:07, Serge E. Hallyn wrote: > > > On Thu, Mar 02, 2017 at 08:10:29PM -0500, Richard Guy Briggs wrote: > > > > The audit subsystem is adding a BPRM_FCA

Re: [PATCH] capabilities: do not audit log BPRM_FCAPS on set*id

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-03-07 12:10, Serge E. Hallyn wrote: > > Quoting Richard Guy Briggs (r...@redhat.com): > > > On 2017-03-02 21:50, Richard Guy Briggs wrote: > > > > On 2017-03-02 20:07, Serge E. Hallyn wrote: > > > >

Re: [PATCH] capabilities: do not audit log BPRM_FCAPS on set*id

On Thu, Mar 02, 2017 at 08:10:29PM -0500, Richard Guy Briggs wrote: > The audit subsystem is adding a BPRM_FCAPS record when auditing setuid > application execution (SYSCALL execve). This is not expected as it was > supposed to be limited to when the file system actually had capabilities > in an

Re: [RFC PATCH V2 1/4] capabilities: use macros to make the logic easier to follow and verify

Quoting Richard Guy Briggs (r...@redhat.com): > This change is intended to be logic-neutral and simply make the logic easier > to > read in natural language and verify without getting distracted by details. > > Signed-off-by: Richard Guy Briggs > --- > security/commoncap.c |

Re: [RFC PATCH V2 1/4] capabilities: use macros to make the logic easier to follow and verify

On Thu, May 11, 2017 at 04:42:40PM -0400, Richard Guy Briggs wrote: > This change is intended to be logic-neutral and simply make the logic easier > to > read in natural language and verify without getting distracted by details. > > Signed-off-by: Richard Guy Briggs > --- >

Re: [PATCH 2/9] Implement containers as kernel objects

Quoting Richard Guy Briggs (r...@redhat.com): ... > > I believe we are going to need a container ID to container definition > > (namespace, etc.) mapping mechanism regardless of if the container ID > > is provided by userspace or a kernel generated serial number. This > > mapping should be

Re: [PATCH V3 09/10] capabilities: fix logic for effective root or real root

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-08-24 11:29, Serge E. Hallyn wrote: > > Quoting Richard Guy Briggs (r...@redhat.com): > > > Now that the logic is inverted, it is much easier to see that both real > > > root > > > and effective ro

Re: [PATCH V3 02/10] capabilities: intuitive names for cap gain status

Quoting Andy Lutomirski (l...@kernel.org): > On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs wrote: > > Introduce macros cap_gained, cap_grew, cap_full to make the use of the > > negation of is_subset() easier to read and analyse. > > > > Signed-off-by: Richard Guy Briggs

Re: [PATCH V3 05/10] capabilities: use intuitive names for id changes

Quoting Andy Lutomirski (l...@amacapital.net): > > > > --Andy > > On Aug 25, 2017, at 11:51 AM, Serge E. Hallyn <se...@hallyn.com> wrote: > > > > Quoting Andy Lutomirski (l...@kernel.org): > >>> On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs

Re: [PATCH V3 01/10] capabilities: factor out cap_bprm_set_creds privileged root

Quoting Richard Guy Briggs (r...@redhat.com): > Factor out the case of privileged root from the function > cap_bprm_set_creds() to make the latter easier to read and analyse. > > Suggested-by: Serge Hallyn Reviewed-by: Serge Hallyn > Signed-off-by: Richard

Re: [PATCH V3 02/10] capabilities: intuitive names for cap gain status

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-08-24 11:03, Serge E. Hallyn wrote: > > Quoting Richard Guy Briggs (r...@redhat.com): > > > Introduce macros cap_gained, cap_grew, cap_full to make the use of the > > > negation of is_subset() easier to read and a

Re: [PATCH V3 03/10] capabilities: rename has_cap to has_fcap

Quoting Richard Guy Briggs (r...@redhat.com): > Rename has_cap to has_fcap to clarify it applies to file capabilities > since the entire source file is about capabilities. > > Signed-off-by: Richard Guy Briggs Reviewed-by: Serge Hallyn > --- >

Re: [PATCH V3 08/10] capabilities: invert logic for clarity

Quoting Richard Guy Briggs (r...@redhat.com): > The way the logic was presented, it was awkward to read and verify. Invert > the > logic using DeMorgan's Law to be more easily able to read and understand. > > Signed-off-by: Richard Guy Briggs Reviewed-by: Serge Hallyn

Re: [PATCH V3 07/10] capabilities: remove a layer of conditional logic

Quoting Andy Lutomirski (l...@kernel.org): > On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs wrote: > > Remove a layer of conditional logic to make the use of conditions > > easier to read and analyse. > > > > Signed-off-by: Richard Guy Briggs > > --- > >

Re: [PATCH V3 06/10] capabilities: move audit log decision to function

Quoting Richard Guy Briggs (r...@redhat.com): > Move the audit log decision logic to its own function to isolate the > complexity in one place. > > Suggested-by: Serge Hallyn Reviewed-by: Serge Hallyn > Signed-off-by: Richard Guy Briggs >

Re: [PATCH V3 05/10] capabilities: use intuitive names for id changes

Quoting Richard Guy Briggs (r...@redhat.com): > Introduce a number of inlines to make the use of the negation of > uid_eq() easier to read and analyse. > > Signed-off-by: Richard Guy Briggs Reviewed-by: Serge Hallyn > --- > security/commoncap.c | 26

Re: [PATCH V3 09/10] capabilities: fix logic for effective root or real root

Quoting Richard Guy Briggs (r...@redhat.com): > Now that the logic is inverted, it is much easier to see that both real root > and effective root conditions had to be met to avoid printing the BPRM_FCAPS > record with audit syscalls. This meant that any setuid root applications > would > print a

Re: [PATCH V3 10/10] capabilities: audit log other surprising conditions

Quoting Richard Guy Briggs (r...@redhat.com): > The existing condition tested for process effective capabilities set by file > attributes but intended to ignore the change if the result was unsurprisingly > an > effective full set in the case root is special with a setuid root executable > file

Re: [PATCH V3 04/10] capabilities: use root_priveleged inline to clarify logic

Quoting Richard Guy Briggs (r...@redhat.com): > Introduce inline root_privileged() to make use of SECURE_NONROOT > easier to read. > > Suggested-by: Serge Hallyn Reviewed-by: Serge Hallyn > Signed-off-by: Richard Guy Briggs > --- >

Re: [PATCH V3 07/10] capabilities: remove a layer of conditional logic

Quoting Richard Guy Briggs (r...@redhat.com): > Remove a layer of conditional logic to make the use of conditions > easier to read and analyse. > > Signed-off-by: Richard Guy Briggs Reviewed-by: Serge Hallyn > --- > security/commoncap.c | 13 ++---

Re: [PATCH V3 02/10] capabilities: intuitive names for cap gain status

Quoting Richard Guy Briggs (r...@redhat.com): > Introduce macros cap_gained, cap_grew, cap_full to make the use of the > negation of is_subset() easier to read and analyse. > > Signed-off-by: Richard Guy Briggs > --- > security/commoncap.c | 16 ++-- > 1 files

Re: [PATCH V3 02/10] capabilities: intuitive names for cap gain status

On Fri, Sep 01, 2017 at 06:18:43AM -0400, Richard Guy Briggs wrote: > On 2017-08-28 07:08, Richard Guy Briggs wrote: > > On 2017-08-28 05:19, Richard Guy Briggs wrote: > > > On 2017-08-24 12:06, Kees Cook wrote: > > > > On Thu, Aug 24, 2017 at 9:37 AM, Ser

Re: [PATCH V3 04/10] capabilities: use root_priveleged inline to clarify logic

Quoting Richard Guy Briggs (r...@redhat.com): > On 2017-08-25 15:58, James Morris wrote: > > On Wed, 23 Aug 2017, Richard Guy Briggs wrote: > > > > > Introduce inline root_privileged() to make use of SECURE_NONROOT > > > easier to read. > > > > > > Suggested-by: Serge Hallyn >

Re: RFC(V3): Audit Kernel Container IDs

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote: > On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote: > > Containers are a userspace concept. The kernel knows nothing of them. > > > > The Linux audit system needs a way to be able to track the container > >

Re: [RFC PATCH V1 00/12] audit: implement container id

Quoting Richard Guy Briggs (r...@redhat.com): > Implement audit kernel container ID. > > This patchset is a preliminary RFC based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html Patchset looks good to me. Acked-by: Serge

Re: [RFC PATCH V1 01/12] audit: add container id

On Thu, Mar 01, 2018 at 02:41:04PM -0500, Richard Guy Briggs wrote: ... > +static inline bool audit_containerid_set(struct task_struct *tsk) Hi Richard, the calls to audit_containerid_set() confused me. Could you make it is_audit_containerid_set() or audit_containerid_isset()? > +{ > +

Re: [PATCH ghak103 V1] audit: add support for fcaps v3

On Wed, Jan 23, 2019 at 09:36:25PM -0500, Richard Guy Briggs wrote: > V3 namespaced file capabilities were introduced in > commit 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") > > Add support for these by adding the "frootid" field to the existing > fcaps fields in the NAME and

Re: [PATCH ghak90 V6 02/10] audit: add container id

On Wed, May 29, 2019 at 06:39:48PM -0400, Paul Moore wrote: > On Wed, May 29, 2019 at 6:28 PM Tycho Andersen wrote: > > On Wed, May 29, 2019 at 12:03:58PM -0400, Paul Moore wrote: > > > On Wed, May 29, 2019 at 11:34 AM Tycho Andersen wrote: > > > > > > > > On Wed, May 29, 2019 at 11:29:05AM

Re: [PATCH v2 10/39] inode: add idmapped mount aware init and permission helpers

On Sun, Nov 15, 2020 at 11:36:49AM +0100, Christian Brauner wrote: > The inode_owner_or_capable() helper determines whether the caller is the > owner of the inode or is capable with respect to that inode. Allow it to > handle idmapped mounts. If the inode is accessed through an idmapped mount > we

Re: [PATCH 00/34] fs: idmapped mounts

On Fri, Oct 30, 2020 at 01:01:57PM +0100, Christian Brauner wrote: > On Thu, Oct 29, 2020 at 02:58:55PM -0700, Andy Lutomirski wrote: > > > > > > > On Oct 28, 2020, at 5:35 PM, Christian Brauner > > > wrote: > > > > > > Hey everyone, > > > > > > I vanished for a little while to focus on

Re: [PATCH 00/34] fs: idmapped mounts

On Fri, Oct 30, 2020 at 10:07:48AM -0500, Seth Forshee wrote: > On Thu, Oct 29, 2020 at 11:37:23AM -0500, Eric W. Biederman wrote: > > First and foremost: A uid shift on write to a filesystem is a security > > bug waiting to happen. This is especially in the context of facilities > > like

Re: [PATCH 00/34] fs: idmapped mounts

On Thu, Oct 29, 2020 at 10:12:31AM -0600, Tycho Andersen wrote: > Hi Eric, > > On Thu, Oct 29, 2020 at 10:47:49AM -0500, Eric W. Biederman wrote: > > Christian Brauner writes: > > > > > Hey everyone, > > > > > > I vanished for a little while to focus on this work here so sorry for > > > not

Re: [PATCH 00/34] fs: idmapped mounts

On Thu, Oct 29, 2020 at 11:37:23AM -0500, Eric W. Biederman wrote: > Aleksa Sarai writes: > > > On 2020-10-29, Eric W. Biederman wrote: > >> Christian Brauner writes: > >> > >> > Hey everyone, > >> > > >> > I vanished for a little while to focus on this work here so sorry for > >> > not being

Re: [PATCH] audit: add task history record

On Sat, Aug 19, 2023 at 04:09:46PM +0900, Tetsuo Handa wrote: > Anyway, enabling TOMOYO in Fedora/RHEL kernels won't solve the problem > this patch is trying to solve, for TOMOYO cannot utilize TOMOYO's process > history information because LSM hook for sending signals does not allow > TOMOYO to

Re: [PATCH RFC] LSM: lsm_self_attr system call to get security module attributes

On Fri, Sep 09, 2022 at 06:01:33PM -0700, Casey Schaufler wrote: > This is probably a tin-man proposal for the first in a series of > system calls dealing with Linux security module data. It is based > on suggestions by Paul Moore, however the flaws in design and > implementation are all mine. >