Re: [RFC PATCH V1 01/12] audit: add container id
On 2018-03-15 16:27, Stefan Berger wrote:
> On 03/01/2018 02:41 PM, Richard Guy Briggs wrote:
> > Implement the proc fs write to set the audit container ID of a process,
> > emitting an AUDIT_CONTAINER record to document the event.
> >
> > This is a write from the container orchestrator task to a proc entry of
> > the form /proc/PID/containerid where PID is the process ID of the newly
> > created task that is to become the first task in a container, or an
> > additional task added to a container.
> >
> > The write expects up to a u64 value (unset: 18446744073709551615).
> >
> > This will produce a record such as this:
> > type=UNKNOWN[1333] msg=audit(1519903238.968:261): op=set pid=596 uid=0
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0
> > ses=1 opid=596 old-contid=18446744073709551615 contid=123455 res=0
> >
> > The "op" field indicates an initial set. The "pid" to "ses" fields are
> > the orchestrator while the "opid" field is the object's PID, the process
> > being "contained". Old and new container ID values are given in the
> > "contid" fields, while res indicates its success.
> >
> > It is not permitted to self-set, unset or re-set the container ID. A
> > child inherits its parent's container ID, but then can be set only once
> > after.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/32
> >
> >
> > /* audit_rule_data supports filter rules with both integer and string
> >* fields. It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 4e0a4ac..0ee1e59 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2073,6 +2073,92 @@ int audit_set_loginuid(kuid_t loginuid)
> > return rc;
> > }
> >
> > +static int audit_set_containerid_perm(struct task_struct *task, u64
> > containerid)
> > +{
> > + struct task_struct *parent;
> > + u64 pcontainerid, ccontainerid;
> > + pid_t ppid;
> > +
> > + /* Don't allow to set our own containerid */
> > + if (current == task)
> > + return -EPERM;
> > + /* Don't allow the containerid to be unset */
> > + if (!cid_valid(containerid))
> > + return -EINVAL;
> > + /* if we don't have caps, reject */
> > + if (!capable(CAP_AUDIT_CONTROL))
> > + return -EPERM;
> > + /* if containerid is unset, allow */
> > + if (!audit_containerid_set(task))
> > + return 0;
>
> I am wondering whether there should be a check for the target process that
> will receive the containerid to not have CAP_SYS_ADMIN that would otherwise
> allow it to arbitrarily unshare()/clone() and leave the set of namespaces
> that may make up the container whose containerid we assign here?
This is a reasonable question. This has been debated and I understood
the conclusion was that without a clear definition of a "container", the
task still remains in that container that just now has more
sub-namespaces (in the case of hierarchical namespaces), we don't want
to restrict it in such a way and that allows it to create nested
containers. I see setns being more problematic if it could switch to
another existing namespace that was set up by the orchestrator for a
different container. The coming v2 patchset acknowledges this situation
with the network namespace being potentially shared by multiple
containers.
This is the motivation for the code below that allows to set the
containerid even if it is already inherited from its parent.
> > + /* it is already set, and not inherited from the parent, reject */
> > + ccontainerid = audit_get_containerid(task);
> > + rcu_read_lock();
> > + parent = rcu_dereference(task->real_parent);
> > + rcu_read_unlock();
> > + task_lock(parent);
> > + pcontainerid = audit_get_containerid(parent);
> > + ppid = task_tgid_nr(parent);
>
> ppid not needed...
Thanks for catching this. It was the vestige of a failed devel
experiment that didn't flush that useless appendage. :-)
> > + task_unlock(parent);
> > + if (ccontainerid != pcontainerid)
> > + return -EPERM;
> > + return 0;
> > +}
> > +
> > +static void audit_log_set_containerid(struct task_struct *task, u64
> > oldcontainerid,
> > + u64 containerid, int rc)
> > +{
> > + struct audit_buffer *ab;
> > + uid_t uid;
> > + struct tty_struct *tty;
> > +
> > + if (!audit_enabled)
> > + return;
> > +
> > + ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONTAINER);
> > + if (!ab)
> > + return;
> > +
> > + uid = from_kuid(&init_user_ns, task_uid(current));
> > + tty = audit_get_tty(current);
> > +
> > + audit_log_format(ab, "op=set pid=%d uid=%u", task_tgid_nr(current),
> > uid);
> > + audit_log_task_context(ab);
> > + audit_log_format(ab, " auid=%u tty=%s ses=%u opid=%d old-contid=%llu
> > contid=%llu res=%d",
> > +from_kuid(&init_user_ns, audit_get_loginuid(current)),
> > +tty ? tty_name
Re: [RFC PATCH V1 01/12] audit: add container id
On 03/01/2018 02:41 PM, Richard Guy Briggs wrote:
Implement the proc fs write to set the audit container ID of a process,
emitting an AUDIT_CONTAINER record to document the event.
This is a write from the container orchestrator task to a proc entry of
the form /proc/PID/containerid where PID is the process ID of the newly
created task that is to become the first task in a container, or an
additional task added to a container.
The write expects up to a u64 value (unset: 18446744073709551615).
This will produce a record such as this:
type=UNKNOWN[1333] msg=audit(1519903238.968:261): op=set pid=596 uid=0
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0
ses=1 opid=596 old-contid=18446744073709551615 contid=123455 res=0
The "op" field indicates an initial set. The "pid" to "ses" fields are
the orchestrator while the "opid" field is the object's PID, the process
being "contained". Old and new container ID values are given in the
"contid" fields, while res indicates its success.
It is not permitted to self-set, unset or re-set the container ID. A
child inherits its parent's container ID, but then can be set only once
after.
See: https://github.com/linux-audit/audit-kernel/issues/32
/* audit_rule_data supports filter rules with both integer and string
* fields. It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 4e0a4ac..0ee1e59 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2073,6 +2073,92 @@ int audit_set_loginuid(kuid_t loginuid)
return rc;
}
+static int audit_set_containerid_perm(struct task_struct *task, u64
containerid)
+{
+ struct task_struct *parent;
+ u64 pcontainerid, ccontainerid;
+ pid_t ppid;
+
+ /* Don't allow to set our own containerid */
+ if (current == task)
+ return -EPERM;
+ /* Don't allow the containerid to be unset */
+ if (!cid_valid(containerid))
+ return -EINVAL;
+ /* if we don't have caps, reject */
+ if (!capable(CAP_AUDIT_CONTROL))
+ return -EPERM;
+ /* if containerid is unset, allow */
+ if (!audit_containerid_set(task))
+ return 0;
I am wondering whether there should be a check for the target process
that will receive the containerid to not have CAP_SYS_ADMIN that would
otherwise allow it to arbitrarily unshare()/clone() and leave the set of
namespaces that may make up the container whose containerid we assign here?
+ /* it is already set, and not inherited from the parent, reject */
+ ccontainerid = audit_get_containerid(task);
+ rcu_read_lock();
+ parent = rcu_dereference(task->real_parent);
+ rcu_read_unlock();
+ task_lock(parent);
+ pcontainerid = audit_get_containerid(parent);
+ ppid = task_tgid_nr(parent);
ppid not needed...
+ task_unlock(parent);
+ if (ccontainerid != pcontainerid)
+ return -EPERM;
+ return 0;
+}
+
+static void audit_log_set_containerid(struct task_struct *task, u64
oldcontainerid,
+ u64 containerid, int rc)
+{
+ struct audit_buffer *ab;
+ uid_t uid;
+ struct tty_struct *tty;
+
+ if (!audit_enabled)
+ return;
+
+ ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONTAINER);
+ if (!ab)
+ return;
+
+ uid = from_kuid(&init_user_ns, task_uid(current));
+ tty = audit_get_tty(current);
+
+ audit_log_format(ab, "op=set pid=%d uid=%u", task_tgid_nr(current),
uid);
+ audit_log_task_context(ab);
+ audit_log_format(ab, " auid=%u tty=%s ses=%u opid=%d old-contid=%llu
contid=%llu res=%d",
+from_kuid(&init_user_ns, audit_get_loginuid(current)),
+tty ? tty_name(tty) : "(none)",
audit_get_sessionid(current),
+task_tgid_nr(task), oldcontainerid, containerid, !rc);
+
+ audit_put_tty(tty);
+ audit_log_end(ab);
+}
+
+/**
+ * audit_set_containerid - set current task's audit_context containerid
+ * @containerid: containerid value
+ *
+ * Returns 0 on success, -EPERM on permission failure.
+ *
+ * Called (set) from fs/proc/base.c::proc_containerid_write().
+ */
+int audit_set_containerid(struct task_struct *task, u64 containerid)
+{
+ u64 oldcontainerid;
+ int rc;
+
+ oldcontainerid = audit_get_containerid(task);
+
+ rc = audit_set_containerid_perm(task, containerid);
+ if (!rc) {
+ task_lock(task);
+ task->containerid = containerid;
+ task_unlock(task);
+ }
+
+ audit_log_set_containerid(task, oldcontainerid, containerid, rc);
+ return rc;
+}
+
/**
* __audit_mq_open - record audit data for a POSIX MQ open
* @oflag: open flag
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: Matching close() system calls
On Wed, 14 Mar 2018 15:51:44 +0300 Kerem Aksu wrote: > Hello, > > I am trying to trace files by using this rule : > "-a always,exit -F arch=b64 -S read,write,open,close -k file_op" > > I can trace open() system calls with the "type=path" log occurred > with the same ID as the open() system call. I can learn which file is > opened by that open() system call. If open returns a non-negative number, then that is the descriptor. You'll need to match that descriptor as an argument to the other syscalls for the same pid. You might need to watch exit_group also since a program exiting closes all descriptors. And also you'll need to check flags set by open and fcntl to see if CLOEXEC is being set. > But when it comes to other system calls I am unable to learn which > file is read, wrote or closed. This is implicit by referencing the descriptor. > I tried to match arguments passed to system calls (a[0..3]) but those > are different than the arguments defined in linux man pages. I might > misunderstand these arguments. No, they are pretty much the same. > How can I match these or any other (file) system calls with the files > that they used onto. > And when does a "type=PATH" log occurs? You'll probably need to write a program using auparse to save the descriptor from an open or openat and then output the information you need as a custom program. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Matching close() system calls
Hello, I am trying to trace files by using this rule : "-a always,exit -F arch=b64 -S read,write,open,close -k file_op" I can trace open() system calls with the "type=path" log occurred with the same ID as the open() system call. I can learn which file is opened by that open() system call. But when it comes to other system calls I am unable to learn which file is read, wrote or closed. I tried to match arguments passed to system calls (a[0..3]) but those are different than the arguments defined in linux man pages. I might misunderstand these arguments. How can I match these or any other (file) system calls with the files that they used onto. And when does a "type=PATH" log occurs? Thanks. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated
On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina wrote: > On Wed, 14 Mar 2018, Andy Lutomirski wrote: > >> > Yes...I wished I was in on the beginning of this discussion. Here's the >> > problem. We need all tasks auditable unless specifically dismissed as >> > uninteresting. This would be a task,never rule. >> > >> > The way we look at it, is if it boots with audit=1, then we know auditd >> > is expected to run at some point. So, we need all tasks to stay >> > auditable. If they weren't and auditd enabled auditing, then we'd need >> > to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every >> > process in the system. It was decided that this is too ugly. >> >> When was that decided? That's what this patch does. > > I'd like to see some more justification as well. > > Namely, if I compare "setting TIF_AUDIT_SYSCALL for every process on a > need-to-be-so basis" to "we always go through the slow path and > pessimistically assume that audit is enabled and has reasonable ruleset > loaded", I have my own (different) opinion of what is too ugly. Me too. That being said, on re-review of my old code, I think that audit_dec_n_rules() may be the wrong approach. It may be better to leave TIF_AUDIT_SYSCALL set but to make the audit code itself clear the flag the next time through. That way we don't end up with a partially filled in syscall audit record that never gets consumed if we clear TIF_AUDIT_SYSCALL in the middle of a syscall. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names
On 2018-03-13 16:24, Paul Moore wrote: > On Tue, Mar 13, 2018 at 6:52 AM, Richard Guy Briggs wrote: > > On 2018-03-13 11:38, Steve Grubb wrote: > >> On Tue, 13 Mar 2018 06:11:08 -0400 > >> Richard Guy Briggs wrote: > >> > >> > On 2018-03-13 09:35, Steve Grubb wrote: > >> > > On Mon, 12 Mar 2018 11:52: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 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 updating the existing PATH record. > >> > > > > >> > Update the symlink's PATH record with the current dentry > >> > > > > >> > and inode information. > >> > > > > >> > > >> > > > > >> > See: https://github.com/linux-audit/audit-kernel/issues/21 > >> > > > > >> > Signed-off-by: Richard Guy Briggs > >> > > > > >> > --- > >> > > > > >> > fs/namei.c | 1 + > >> > > > > >> > 1 file changed, 1 insertion(+) > >> > > > > >> > >> > > > > >> Why didn't you include this in patch 4/4 like I asked during > >> > > > > >> the previous review? > >> > > > > > > >> > > > > > Please see the last comment of: > >> > > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html > >> > > > > > >> > > > > Yes, I just saw that ... I hadn't seen your replies on the v1 > >> > > > > patches until I had finished reviewing v2. I just replied to > >> > > > > that mail in the v1 thread, but basically you need to figure > >> > > > > out what is necessary here and let us know. If I have to > >> > > > > figure it out it likely isn't going to get done with enough > >> > > > > soak time prior to the upcoming merge window. > >> > > > > >> > > > Steve? I was hoping you could chime in here. > >> > > > >> > > If the CWD record will always be the same as the PARENT record, > >> > > then we do not need the parent record. Duplicate information is > >> > > bad. Like all the duplicate SYSCALL information. > >> > > >> > The CWD record could be different from the PARENT record, since I > >> > could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test. > >> > Does the parent record even matter since it might not be a directory > >> > operation like creat, unlink or rename? > >> > >> There's 2 issues. One is creating the path if what we have is relative. > >> In this situation CWD should be enough. But if the question is whether > >> the PARENT directory should be included...what if the PARENT > >> permissions do not allow the successful name resolution? In that case > >> we might only get a PARENT record no? In that case we would need it. > > > > I think in the case of symlink creation, normal file create code path > > would be in effect, and would properly log parent and symlink source > > file paths (if a rule to log it was in effect) which is not something > > that would trigger a symlink link denied error. Symlink link denied > > happens only when trying to actually follow the link before > > resolving the target path of a read/write/exec of the symlink target. > > > > If the parent permissions of the link's target don't allow successful > > name resolution then the symlink link denied condition isn't met, but > > rather any other rule that applies to the target path. > > I'm guessing you are in the process of tracking all this down, but if > not, lets get to a point where we can answer this definitively and not > guess :) I was fairly certain but being polite, expecting confirmation or possibly correction if I've overlooked something. Additionally, this denial message only happens in certain parts of the permission check for symlinks: /proc/sys/fs/protected_symlinks == 1 and follower and link owner don't match and parent sticky and world-writable and link parent and link owner don't match If you want other symlink denials logged, you need to set a rule for the target filtering on operation failure such as unix file permissions. The similar situation exists for hardlinks. > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak21 V3 1/2] audit: remove path param from link denied function
In commit 45b578fe4c3cade6f4ca1fc934ce199afd857edc
("audit: link denied should not directly generate PATH record")
the need for the struct path *link parameter was removed.
Remove the now useless struct path argument.
Signed-off-by: Richard Guy Briggs
---
fs/namei.c| 2 +-
include/linux/audit.h | 6 ++
kernel/audit.c| 3 +--
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 9cc91fb..50d2533 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1011,7 +1011,7 @@ static int may_linkat(struct path *link)
if (safe_hardlink_source(inode) || inode_owner_or_capable(inode))
return 0;
- audit_log_link_denied("linkat", link);
+ audit_log_link_denied("linkat");
return -EPERM;
}
diff --git a/include/linux/audit.h b/include/linux/audit.h
index af410d9..75d5b03 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -146,8 +146,7 @@ extern void audit_log_d_path(struct
audit_buffer *ab,
const struct path *path);
extern voidaudit_log_key(struct audit_buffer *ab,
char *key);
-extern voidaudit_log_link_denied(const char *operation,
- const struct path *link);
+extern voidaudit_log_link_denied(const char *operation);
extern voidaudit_log_lost(const char *message);
extern int audit_log_task_context(struct audit_buffer *ab);
@@ -194,8 +193,7 @@ static inline void audit_log_d_path(struct audit_buffer *ab,
{ }
static inline void audit_log_key(struct audit_buffer *ab, char *key)
{ }
-static inline void audit_log_link_denied(const char *string,
-const struct path *link)
+static inline void audit_log_link_denied(const char *string)
{ }
static inline int audit_log_task_context(struct audit_buffer *ab)
{
diff --git a/kernel/audit.c b/kernel/audit.c
index 3f2f143..e8bf8d7 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2308,9 +2308,8 @@ void audit_log_task_info(struct audit_buffer *ab, struct
task_struct *tsk)
/**
* audit_log_link_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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak21 V3 2/2] audit: add refused symlink to audit_names
Audit link denied events for symlinks had duplicate PATH records rather
than just updating the existing PATH record. Update the symlink's PATH
record with the current dentry and inode information.
See: https://github.com/linux-audit/audit-kernel/issues/21
Signed-off-by: Richard Guy Briggs
---
fs/namei.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/namei.c b/fs/namei.c
index 50d2533..00f5041 100644
--- a/fs/namei.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_denied("follow_link", &nd->stack[0].link);
return -EACCES;
}
--
1.8.3.1
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak21 V3 0/2] audit: address ANOM_LINK excess records
This V3 is a supplement to patches 1 and 2 of v1 already merged.
Audit link denied events were being unexpectedly produced in a disjoint
way when audit was disabled, and when they were expected, there were
duplicate PATH records. This patchset addresses both issues for
symlinks and hardlinks.
This was introduced with
commit b24a30a7305418ff138ff51776fc555ec57c011a
("audit: fix event coverage of AUDIT_ANOM_LINK")
commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc
("fs: add link restriction audit reporting")
Here are the resulting events:
symlink:
type=PROCTITLE msg=audit(03/12/2018 02:21:49.578:310) : proctitle=ls
./my-passwd
type=PATH msg=audit(03/12/2018 02:21:49.578:310) : item=0 name=./my-passwd
inode=17090 dev=00:27 mode=link,777 ouid=rgb ogid=rgb rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none cap_fi=none
cap_fe=0 cap_fver=0
type=CWD msg=audit(03/12/2018 02:21:49.578:310) : cwd=/tmp
type=SYSCALL msg=audit(03/12/2018 02:21:49.578:310) : arch=x86_64 syscall=stat
success=no exit=EACCES(Permission denied) a0=0x7ffd79950dda a1=0x563f658a03c8
a2=0x563f658a03c8 a3=0x79950d00 items=2 ppid=552 pid=629 auid=root uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
tty=ttyS0 ses=1 comm=ls exe=/usr/bin/ls
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_LINK msg=audit(03/12/2018 02:21:49.578:310) : op=follow_link ppid=552
pid=629 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=ttyS0 ses=1 comm=ls exe=/usr/bin/ls
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
hardlink:
type=PROCTITLE msg=audit(03/12/2018 02:24:39.813:314) : proctitle=ln test
test-ln
type=PATH msg=audit(03/12/2018 02:24:39.813:314) : item=1 name=/tmp inode=13529
dev=00:27 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0
cap_fver=0
type=PATH msg=audit(03/12/2018 02:24:39.813:314) : item=0 name=test inode=18112
dev=00:27 mode=file,700 ouid=root ogid=root rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none cap_fi=none
cap_fe=0 cap_fver=0
type=CWD msg=audit(03/12/2018 02:24:39.813:314) : cwd=/tmp
type=SYSCALL msg=audit(03/12/2018 02:24:39.813:314) : arch=x86_64
syscall=linkat success=no exit=EPERM(Operation not permitted) a0=0xff9c
a1=0x7ffccba77629 a2=0xff9c a3=0x7ffccba7762e items=2 ppid=605 pid=638
auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb sgid=rgb
fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_LINK msg=audit(03/12/2018 02:24:39.813:314) : op=linkat ppid=605
pid=638 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb sgid=rgb
fsgid=rgb tty=pts0 ses=4 comm=ln exe=/usr/bin/ln
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no
See: https://github.com/linux-audit/audit-kernel/issues/21
See also: https://github.com/linux-audit/audit-kernel/issues/51
Changelog:
v3:
- rebase on previously accepted 1/4 and 2/4 patches and drop them
- drop parent record audit_log_symlink_denied()
v2:
- remove now supperfluous struct path * parameter from audit_log_link_denied()
- refactor audit_log_symlink_denied() to properly free memory (pathname,
filename)
Richard Guy Briggs (2):
audit: remove path param from link denied function
audit: add refused symlink to audit_names
fs/namei.c| 3 ++-
include/linux/audit.h | 6 ++
kernel/audit.c| 3 +--
3 files changed, 5 insertions(+), 7 deletions(-)
--
1.8.3.1
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
