Re: [PATCH V4 01/10] capabilities: factor out cap_bprm_set_creds privileged root
On Tue, 5 Sep 2017, Richard Guy Briggs wrote: > 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 > Signed-off-by: Richard Guy Briggs > Reviewed-by: Serge Hallyn > --- > security/commoncap.c | 63 +++-- > 1 files changed, 35 insertions(+), 28 deletions(-) Acked-by: James Morris -- James Morris -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH] docs: add exclude filter never note
The exclude filter defaults to "never", ignoring the action. Make a note of that to clarify the sense and intent of the filter. Signed-off-by: Richard Guy Briggs --- docs/audit.rules.7 |2 +- docs/audit_add_rule_data.3 |2 +- docs/auditctl.8|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/audit.rules.7 b/docs/audit.rules.7 index 192d42f..042c7dc 100644 --- a/docs/audit.rules.7 +++ b/docs/audit.rules.7 @@ -40,7 +40,7 @@ The exit filter is the place where all syscall and file system audit requests ar The user filter is used to filter (remove) some events that originate in user space. By default, any event originating in user space is allowed. So, if there are some events that you do not want to see, then this is a place where some can be removed. See auditctl(8) for fields that are valid. -The exclude filter is used to exclude certain events from being emitted. The msgtype field is used to tell the kernel which message types you do not want to record. This filter can remove the event as a whole and is not selective about any other attribute. The user and exit filters are better suited to selectively auditing events. +The exclude filter is used to exclude certain events from being emitted. The msgtype and a number of subject attribute fields can be used to tell the kernel which message types you do not want to record. This filter can remove the event as a whole and is not selective about any other attribute. The user and exit filters are better suited to selectively auditing events. The action is ignored for this filter, defaulting to "never". Syscall rules take the general form of: diff --git a/docs/audit_add_rule_data.3 b/docs/audit_add_rule_data.3 index a0802c0..3e9039d 100644 --- a/docs/audit_add_rule_data.3 +++ b/docs/audit_add_rule_data.3 @@ -21,7 +21,7 @@ AUDIT_FILTER_TASK - Apply rule at task creation (not syscall). This is the task AUDIT_FILTER_EXIT - Apply rule at syscall exit. This is the main filter that is used for syscalls and filesystem watches. Normally all syscall do not trigger events, so this is normally used to specify events that are of interest. .TP \(bu -AUDIT_FILTER_TYPE - Apply rule at audit_log_start. This is the exclude filter which discards any records that match. +AUDIT_FILTER_TYPE - Apply rule at audit_log_start. This is the exclude filter which discards any records that match. The action type is ignored for this filter, defaulting to "never". .LP .PP diff --git a/docs/auditctl.8 b/docs/auditctl.8 index 05e389e..88466de 100644 --- a/docs/auditctl.8 +++ b/docs/auditctl.8 @@ -81,7 +81,7 @@ Add a rule to the syscall exit list. This list is used upon exit from a system c Add a rule to the user message filter list. This list is used by the kernel to filter events originating in user space before relaying them to the audit daemon. It should be noted that the only fields that are valid are: uid, auid, gid, pid, subj_user, subj_role, subj_type, subj_sen, subj_clr, and msgtype. All other fields will be treated as non-matching. It should be understood that any event originating from user space from a process that has CAP_AUDIT_WRITE will be recorded into the audit trail. This means that the most likely use for this filter is with rules that have an action of never since nothing has to be done to allow events to be recorded. .TP .B exclude -Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, message type or subject context +Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, message type or subject context. The action is ignored and uses its default of "never". .RE The following describes the valid \fIactions\fP for the rule: -- 1.7.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Why there is no PATH record for change file time syscalls ?(utimensat)
I got only following SYSCALL record in audit log for 'touch -t ' command, no CWD, no PATH recordtype=SYSCALL msg=audit(1503837757.149:266995): arch=c03e syscall=280 success=yes exit=0 a0=0 a1=0 a2=7fffbb26bb10 a3=0 items=0 ppid=101 pid=102 auid=1000 uid=0 gid=31 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1 comm="touch" exe="/bin/touch" key="times" -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> The fanotify interface allows user space daemons to make access
> control decisions. Under common criteria requirements, we need to
> optionally record decisions based on policy. This patch adds a bit mask,
> FAN_AUDIT, that a user space daemon can 'or' into the response decision
> which will tell the kernel that it made a decision and record it.
[Since this is API change, added linux-api to CC, also added Amir since he
works with fanotify]
Hum, probably I'm missing something here but why an application responding
to fanotify event should need to know about audit? Or is it that for CC
requirements you have to implement some deamon which will arbitrate access
using fanotify and you need to have decisions logged using kernel audit
interface?
And another design question: If you need all responses by some daemon
logged, wouldn't it be more logical to make FAN_AUDIT a property of
fanotify instance (i.e., a flag to fanotify_init(2))? Or maybe a property
of fanotify mark (i.e., a flag to fanotify_mark(2))?
> It would be used something like this in user space code:
>
> response.response = FAN_DENY | FAN_AUDIT;
> write(fd, &response, sizeof(struct fanotify_response));
>
> When the syscall ends, the audit system will record the decision as a
> AUDIT_FANOTIFY auxiliary record to denote that the reason this event
> occurred is the result of an access control decision from fanotify
> rather than DAC or MAC policy.
>
> A sample event looks like this:
>
> type=PATH msg=audit(1504310584.332:290): item=0 name="./evil-ls"
> inode=1319561 dev=fc:03 mode=0100755 ouid=1000 ogid=1000 rdev=00:00
> obj=unconfined_u:object_r:user_home_t:s0 nametype=NORMAL
> type=CWD msg=audit(1504310584.332:290): cwd="/home/sgrubb"
> type=SYSCALL msg=audit(1504310584.332:290): arch=c03e syscall=2
> success=no exit=-1 a0=32cb3fca90 a1=0 a2=43 a3=8 items=1 ppid=901
> pid=959 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
> fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="bash"
> exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:
> s0-s0:c0.c1023 key=(null)
> type=FANOTIFY msg=audit(1504310584.332:290): resp=2
>
> Signed-off-by: sgrubb
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 3260ba2..1725f73 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2390,6 +2390,12 @@ void __audit_log_kern_module(char *name)
> context->type = AUDIT_KERN_MODULE;
> }
>
> +void __audit_fanotify(unsigned int response)
> +{
> + audit_log(current->audit_context, GFP_ATOMIC,
> + AUDIT_FANOTIFY, "resp=%u", response);
> +}
Heh, GFP_ATOMIC looks pretty crude and it can fail more often than you'd
think. In fact fanotify uses GFP_KERNEL for allocation of new event and I
don't see a reason why __audit_fanotify() couldn't use the same.
Honza
--
Jan Kara
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED
A few years ago, I suggested a feature dubbed "known exploit detection". This feature defines an interface that allows kernel developers to add a tripwire for somebody who tries to exploit a known security hole in older versions of the kernel. See [1] for an article and the original discussion. [1]: https://lwn.net/Articles/577432/ Due to the somewhat controversial nature of this feature, I never pushed very hard for it to go upstream. However, regardless of whether this code ever makes it upstream, it would still be useful to reserve a numerical code for the audit message in order to ensure that private deployments never conflicts with future upstream kernels. I hereby request the reservation of AUDIT_ANOM_PATCHED as code 1703. This message should be used when userspace makes a request which in previous (unpatched) versions of the kernel would have allowed the process to illicitly gain privileges (e.g. arbitrary code execution, etc.). Signed-off-by: Vegard Nossum --- include/uapi/linux/audit.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h index 0714a66f0e0c..7813efc09480 100644 --- a/include/uapi/linux/audit.h +++ b/include/uapi/linux/audit.h @@ -139,6 +139,7 @@ #define AUDIT_ANOM_PROMISCUOUS 1700 /* Device changed promiscuous mode */ #define AUDIT_ANOM_ABEND1701 /* Process ended abnormally */ #define AUDIT_ANOM_LINK1702 /* Suspicious use of file links */ +#define AUDIT_ANOM_PATCHED 1703 /* Patched security vulnerability */ #define AUDIT_INTEGRITY_DATA 1800 /* Data integrity verification */ #define AUDIT_INTEGRITY_METADATA1801 /* Metadata integrity verification */ #define AUDIT_INTEGRITY_STATUS 1802 /* Integrity enable status */ -- 2.12.0.rc0 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Wed, Sep 6, 2017 at 12:18 PM, Jan Kara wrote: > On Tue 05-09-17 14:32:07, Steve Grubb wrote: >> The fanotify interface allows user space daemons to make access >> control decisions. Under common criteria requirements, we need to >> optionally record decisions based on policy. This patch adds a bit mask, >> FAN_AUDIT, that a user space daemon can 'or' into the response decision >> which will tell the kernel that it made a decision and record it. > > [Since this is API change, added linux-api to CC, also added Amir since he > works with fanotify] > > Hum, probably I'm missing something here but why an application responding > to fanotify event should need to know about audit? Or is it that for CC > requirements you have to implement some deamon which will arbitrate access > using fanotify and you need to have decisions logged using kernel audit > interface? > > And another design question: If you need all responses by some daemon > logged, wouldn't it be more logical to make FAN_AUDIT a property of > fanotify instance (i.e., a flag to fanotify_init(2))? Or maybe a property > of fanotify mark (i.e., a flag to fanotify_mark(2))? > Even if the use case is auditing blocklisted files, the change of ABI on the response fd should be opt-in by a new flag to fanotify_init(), something like FAN_CAN_AUDIT. In other words, your new daemon that responds with FAN_AUDIT must fail to start when running on an old kernel that doesn't support the FAN_AUDIT response, unless it knows how to fall back and call fanotify_init() again without FAN_CAN_AUDIT and then not respond with FAN_AUDIT. Other than that, I agree with Jan that setting FAN_AUDIT by default for all permission responses at fanotify_init() and maybe fanotify_mark() sounds useful. IMO, it makes most sense in proximity to defining the notification class, e.g.: fanotify_init(FAN_CLASS_CONTENT|FAN_PERM_AUDIT, 0); Amir. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED
On 09/05/17 16:39, Paul Moore wrote: On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum wrote: A few years ago, I suggested a feature dubbed "known exploit detection". This feature defines an interface that allows kernel developers to add a tripwire for somebody who tries to exploit a known security hole in older versions of the kernel. See [1] for an article and the original discussion. [1]: https://lwn.net/Articles/577432/ Due to the somewhat controversial nature of this feature, I never pushed very hard for it to go upstream. However, regardless of whether this code ever makes it upstream, it would still be useful to reserve a numerical code for the audit message in order to ensure that private deployments never conflicts with future upstream kernels. I hereby request the reservation of AUDIT_ANOM_PATCHED as code 1703. This message should be used when userspace makes a request which in previous (unpatched) versions of the kernel would have allowed the process to illicitly gain privileges (e.g. arbitrary code execution, etc.). Signed-off-by: Vegard Nossum --- include/uapi/linux/audit.h | 1 + 1 file changed, 1 insertion(+) In general I'm opposed to reserving audit message IDs for kernel code that hasn't been accepted upstream and I don't yet see a compelling reason to do so here. Hi Paul, I only submitted this patch to prevent a potential semantic conflict in the future if mainline gains additional messages codes, which could cause kernel/userspace binary incompatibilities across distros. We can always effectively fork the protocol, but won't you agree that seems more undesirable than adding a message code which remains unused in mainline and otherwise has no maintenance overhead whatsoever? The message itself is well-defined (and has no specific syntactic requirements as far as we're concerned, but we can specify it in detail if that's what you would prefer). To be clear, what I'm trying to achieve here is to avoid a fragmentation of the _protocol_ while still allowing us to make changes to the kernel that nobody else wants to have upstream. It seems like an obvious win-win to me. Thanks, Vegard -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Auditing console access
Hi, The examples found in the audit documentation mention that to work it is assumed that no direct root login is allowed. This very sensible and not a big problem except for console access. What would be the best way to monitor what is done through this access ? Would you recommend to forbid root access even in console ? Philippe !!!* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Tuesday, September 5, 2017 11:24:49 PM EDT Richard Guy Briggs wrote:
> On 2017-09-05 14:32, Steve Grubb wrote:
> > The fanotify interface allows user space daemons to make access
> >
> > control decisions. Under common criteria requirements, we need to
> > optionally record decisions based on policy. This patch adds a bit mask,
> > FAN_AUDIT, that a user space daemon can 'or' into the response decision
> > which will tell the kernel that it made a decision and record it.
> >
> > It would be used something like this in user space code:
> > response.response = FAN_DENY | FAN_AUDIT;
> > write(fd, &response, sizeof(struct fanotify_response));
> >
> > When the syscall ends, the audit system will record the decision as a
> > AUDIT_FANOTIFY auxiliary record to denote that the reason this event
> > occurred is the result of an access control decision from fanotify
> > rather than DAC or MAC policy.
> >
> > A sample event looks like this:
> >
> > type=PATH msg=audit(1504310584.332:290): item=0 name="./evil-ls"
> > inode=1319561 dev=fc:03 mode=0100755 ouid=1000 ogid=1000 rdev=00:00
> > obj=unconfined_u:object_r:user_home_t:s0 nametype=NORMAL
> > type=CWD msg=audit(1504310584.332:290): cwd="/home/sgrubb"
> > type=SYSCALL msg=audit(1504310584.332:290): arch=c03e syscall=2
> > success=no exit=-1 a0=32cb3fca90 a1=0 a2=43 a3=8 items=1 ppid=901
> > pid=959 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
> > fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="bash"
> > exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:
> > s0-s0:c0.c1023 key=(null)
> > type=FANOTIFY msg=audit(1504310584.332:290): resp=2
> >
> > Signed-off-by: sgrubb
>
> In the AUDIT_FANOTIFY record, there is a new field "resp". Should this
> not conform to the existing field types "res" or "result"?
The values used by fanotify are either 1 & 2 rather than 0 & 1. So, it would
need record specific translation. It's easier to just pick a new field name
and key off of that.
-Steve
> Other than that,
> Reviewed-by: Richard Guy Briggs
>
> > ---
> >
> > fs/notify/fanotify/fanotify.c | 8 +++-
> > fs/notify/fanotify/fanotify_user.c | 2 +-
> > include/linux/audit.h | 7 +++
> > include/uapi/linux/audit.h | 1 +
> > include/uapi/linux/fanotify.h | 2 ++
> > kernel/auditsc.c | 6 ++
> > 6 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 2fa99ae..1968d21 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -9,6 +9,7 @@
> >
> > #include
> > #include
> > #include
> >
> > +#include
> >
> > #include "fanotify.h"
> >
> > @@ -78,7 +79,7 @@ static int fanotify_get_response(struct fsnotify_group
> > *group,>
> > fsnotify_finish_user_wait(iter_info);
> >
> > out:
> > /* userspace responded, convert to something usable */
> >
> > - switch (event->response) {
> > + switch (event->response & ~FAN_AUDIT) {
> >
> > case FAN_ALLOW:
> > ret = 0;
> > break;
> >
> > @@ -86,6 +87,11 @@ static int fanotify_get_response(struct fsnotify_group
> > *group,>
> > default:
> > ret = -EPERM;
> >
> > }
> >
> > +
> > + /* Check if the response should be audited */
> > + if (event->response & FAN_AUDIT)
> > + audit_fanotify(event->response & ~FAN_AUDIT);
> > +
> >
> > event->response = 0;
> >
> > pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
> >
> > diff --git a/fs/notify/fanotify/fanotify_user.c
> > b/fs/notify/fanotify/fanotify_user.c index 907a481..b983b5c 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -179,7 +179,7 @@ static int process_access_response(struct
> > fsnotify_group *group,>
> > * userspace can send a valid response or we will clean it up after the
> > * timeout
> > */
> >
> > - switch (response) {
> > + switch (response & ~FAN_AUDIT) {
> >
> > case FAN_ALLOW:
> >
> > case FAN_DENY:
> > break;
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 2150bdc..bf55732 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm
> > *bprm,>
> > extern void __audit_log_capset(const struct cred *new, const struct cred
> > *old); extern void __audit_mmap_fd(int fd, int flags);
> > extern void __audit_log_kern_module(char *name);
> >
> > +extern void __audit_fanotify(unsigned int response);
> >
> > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
> > {
> >
> > @@ -456,6 +457,12 @@ static inline void audit_log_kern_module(char *name)
> >
> > __audit_log_kern_module(name);
> >
> > }
> >
> > +static inline void audit_fanotify(unsigned int response)
> > +{
> > +
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> > The fanotify interface allows user space daemons to make access
> >
> > control decisions. Under common criteria requirements, we need to
> > optionally record decisions based on policy. This patch adds a bit mask,
> > FAN_AUDIT, that a user space daemon can 'or' into the response decision
> > which will tell the kernel that it made a decision and record it.
>
> [Since this is API change, added linux-api to CC, also added Amir since he
> works with fanotify]
>
> Hum, probably I'm missing something here but why an application responding
> to fanotify event should need to know about audit?
Common Criteria rules are that if anything can prevent a flow of information,
then you must be able to selectively audit. Selectively audit means under
admin direction only when they want it. Meaning they may want some denials or
approvals but not other ones.
> Or is it that for CCrequirements you have to implement some deamon which
> will arbitrate access using fanotify and you need to have decisions logged
> using kernel audit interface?
Yes. And even virus scanners would probably want to allow admins to pick when
they record something being blocked.
> And another design question: If you need all responses by some daemon
> logged, wouldn't it be more logical to make FAN_AUDIT a property of
> fanotify instance (i.e., a flag to fanotify_init(2))? Or maybe a property
> of fanotify mark (i.e., a flag to fanotify_mark(2))?
It needs to be selectively audited. Meaning that most of the time it stays out
of the way, but when an admin wants the information they have the ability make
it happen. The example code below is overly simplistic. You would normally
calculate the access decision and then check if auditing is requested and then
'or' in the audit bit if needed.
> > It would be used something like this in user space code:
> > response.response = FAN_DENY | FAN_AUDIT;
> > write(fd, &response, sizeof(struct fanotify_response));
> >
> > When the syscall ends, the audit system will record the decision as a
> > AUDIT_FANOTIFY auxiliary record to denote that the reason this event
> > occurred is the result of an access control decision from fanotify
> > rather than DAC or MAC policy.
> >
> > A sample event looks like this:
> >
> > type=PATH msg=audit(1504310584.332:290): item=0 name="./evil-ls"
> > inode=1319561 dev=fc:03 mode=0100755 ouid=1000 ogid=1000 rdev=00:00
> > obj=unconfined_u:object_r:user_home_t:s0 nametype=NORMAL
> > type=CWD msg=audit(1504310584.332:290): cwd="/home/sgrubb"
> > type=SYSCALL msg=audit(1504310584.332:290): arch=c03e syscall=2
> > success=no exit=-1 a0=32cb3fca90 a1=0 a2=43 a3=8 items=1 ppid=901
> > pid=959 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
> > fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="bash"
> > exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:
> > s0-s0:c0.c1023 key=(null)
> > type=FANOTIFY msg=audit(1504310584.332:290): resp=2
> >
> > Signed-off-by: sgrubb
>
>
>
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 3260ba2..1725f73 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2390,6 +2390,12 @@ void __audit_log_kern_module(char *name)
> >
> > context->type = AUDIT_KERN_MODULE;
> >
> > }
> >
> > +void __audit_fanotify(unsigned int response)
> > +{
> > + audit_log(current->audit_context, GFP_ATOMIC,
> > + AUDIT_FANOTIFY, "resp=%u", response);
> > +}
>
> Heh, GFP_ATOMIC looks pretty crude and it can fail more often than you'd
> think. In fact fanotify uses GFP_KERNEL for allocation of new event and I
> don't see a reason why __audit_fanotify() couldn't use the same.
Sure, that's easy enough to change. Is that the only change needed? Is the
choice of 0x80 for the FAN_AUDIT bit OK? I wanted to leave some room for other
numbers if there ever was a new use. The number is arbitrary and could be
anything.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED
On Wed, Sep 6, 2017 at 9:20 AM, Vegard Nossum wrote: > On 09/05/17 16:39, Paul Moore wrote: >> >> On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum >> wrote: >>> >>> A few years ago, I suggested a feature dubbed "known exploit detection". >>> This feature defines an interface that allows kernel developers to add >>> a tripwire for somebody who tries to exploit a known security hole in >>> older versions of the kernel. See [1] for an article and the original >>> discussion. >>> >>> [1]: https://lwn.net/Articles/577432/ >>> >>> Due to the somewhat controversial nature of this feature, I never pushed >>> very hard for it to go upstream. However, regardless of whether this code >>> ever makes it upstream, it would still be useful to reserve a numerical >>> code for the audit message in order to ensure that private deployments >>> never conflicts with future upstream kernels. >>> >>> I hereby request the reservation of AUDIT_ANOM_PATCHED as code 1703. This >>> message should be used when userspace makes a request which in previous >>> (unpatched) versions of the kernel would have allowed the process to >>> illicitly gain privileges (e.g. arbitrary code execution, etc.). >>> >>> Signed-off-by: Vegard Nossum >>> --- >>> include/uapi/linux/audit.h | 1 + >>> 1 file changed, 1 insertion(+) >> >> >> In general I'm opposed to reserving audit message IDs for kernel code >> that hasn't been accepted upstream and I don't yet see a compelling >> reason to do so here. > > > Hi Paul, > > I only submitted this patch to prevent a potential semantic conflict in > the future if mainline gains additional messages codes, which could > cause kernel/userspace binary incompatibilities across distros. We can > always effectively fork the protocol, but won't you agree that seems > more undesirable than adding a message code which remains unused in > mainline and otherwise has no maintenance overhead whatsoever? The > message itself is well-defined (and has no specific syntactic > requirements as far as we're concerned, but we can specify it in detail > if that's what you would prefer). > > To be clear, what I'm trying to achieve here is to avoid a fragmentation > of the _protocol_ while still allowing us to make changes to the kernel > that nobody else wants to have upstream. It seems like an obvious > win-win to me. >From what I can see you are asking upstream to make accommodations for a patchset that has not been merged in several years, nor are there any plans of pushing this functionality forward upstream, yes? If that is the case, the answer remains "no". I understand your maintenance concern (I also wear a distro "hat" for my day job), but it is well established that distributions which merge out-of-tree kernel code must also bear the maintenance responsibility of that code. Upstream can not be responsible for out-of-tree and distribution specific kernel changes. If you want upstream to reserve a audit record number you will need to get your patchset accepted upstream. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Wednesday, September 6, 2017 7:11:48 AM EDT Amir Goldstein wrote: > On Wed, Sep 6, 2017 at 12:18 PM, Jan Kara wrote: > > On Tue 05-09-17 14:32:07, Steve Grubb wrote: > >> The fanotify interface allows user space daemons to make access > >> > >> control decisions. Under common criteria requirements, we need to > >> optionally record decisions based on policy. This patch adds a bit mask, > >> FAN_AUDIT, that a user space daemon can 'or' into the response decision > >> which will tell the kernel that it made a decision and record it. > > > > [Since this is API change, added linux-api to CC, also added Amir since he > > works with fanotify] > > > > Hum, probably I'm missing something here but why an application responding > > to fanotify event should need to know about audit? Or is it that for CC > > requirements you have to implement some deamon which will arbitrate access > > using fanotify and you need to have decisions logged using kernel audit > > interface? > > > > And another design question: If you need all responses by some daemon > > logged, wouldn't it be more logical to make FAN_AUDIT a property of > > fanotify instance (i.e., a flag to fanotify_init(2))? Or maybe a property > > of fanotify mark (i.e., a flag to fanotify_mark(2))? > > Even if the use case is auditing blocklisted files, the change of ABI on the > response fd should be opt-in by a new flag to fanotify_init(), something > like FAN_CAN_AUDIT. > > In other words, your new daemon that responds with FAN_AUDIT must > fail to start when running on an old kernel that doesn't support the > FAN_AUDIT response, unless it knows how to fall back and call > fanotify_init() again without > FAN_CAN_AUDIT and then not respond with FAN_AUDIT. OK. That's easy enough to add and makes sense. When a daemon tries to audit on a kernel that doesn't, the response is rejected and the system eventually hangs. Killing the daemon fixes it. > Other than that, I agree with Jan that setting FAN_AUDIT by default for > all permission responses at fanotify_init() and maybe fanotify_mark() > sounds useful. > IMO, it makes most sense in proximity to defining the notification class, > e.g.: fanotify_init(FAN_CLASS_CONTENT|FAN_PERM_AUDIT, 0); Its supposed to be selective. The idea is to not force a blanket policy but let the daemon determine by the policy its enforcing whether or not the admin wanted the events. So, the design places exact control in the daemon that responds. For example, the admin may want events only associated with a specific user, directory, file type, file hash, specific file content, etc. but not others. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
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 recorded in the audit log when the container ID is > > created/defined. > > Agreed. > > > > As was suggested in one of the previous threads, if there are any events > > > not > > > associated with a task (incoming network packets) we log the namespace ID > > > and > > > then only concern ourselves with its container serial number or container > > > name > > > once it becomes associated with a task at which point that tracking will > > > be > > > more important anyways. > > > > Agreed. After all, a single namespace can be shared between multiple > > containers. For those security officers who need to track individual > > events like this they will have the container ID mapping information > > in the logs as well so they should be able to trace the unassociated > > event to a set of containers. > > > > > I'm not convinced that a userspace or kernel generated UUID is that useful > > > since they are large, not human readable and may not be globally unique > > > given > > > the "pets vs cattle" direction we are going with potentially identical > > > conditions in hosts or containers spawning containers, but I see no need > > > to > > > restrict them. > > > > From a kernel perspective I think an int should suffice; after all, > > you can't have more containers then you have processes. If the > > container engine requires something more complex, it can use the int > > as input to its own mapping function. > > PIDs roll over. That already causes some ambiguity in reporting. If a > system is constantly spawning and reaping containers, especially > single-process containers, I don't want to have to worry about that ID > rolling to keep track of it even though there should be audit records of > the spawn and death of each container. There isn't significant cost > added here compared with some of the other overhead we're dealing with. Strawman proposal: 1. Each clone/unshare/setns involving a namespace type generates an audit message along the lines of: PID 9512 (pid in init_pid_ns) in auditnsid 0001 cloned CLONE_NEWNS|CLONE_NEWNET new auditnsid: 0002 associated namespaces: (list of all namespace filesystem inode numbers) 2. Userspace (i.e. the container logging deamon here) can watch the audit log for all messages relating to auditnsid 0002. Presumably there will be messages along the lines of "PID 9513 in auditnsid 0002 cloned...". The container logging daemon can track those messages and add the new auditnsids to the list it watches. 3. If a container is migrated (checkpointed and restored here or elsewhere), userspace can just follow the appropriate logs for the new containers. Userspace does not ever *request* a auditnsid. They are ephemeral, just a tool to track the namespaces through the audit log. They are however guaranteed to never be re-used until reboot. (Feels like someone must have proposed this before) -serge -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On 2017-09-06 10:20, Steve Grubb wrote:
> On Tuesday, September 5, 2017 11:24:49 PM EDT Richard Guy Briggs wrote:
> > On 2017-09-05 14:32, Steve Grubb wrote:
> > > The fanotify interface allows user space daemons to make access
> > >
> > > control decisions. Under common criteria requirements, we need to
> > > optionally record decisions based on policy. This patch adds a bit mask,
> > > FAN_AUDIT, that a user space daemon can 'or' into the response decision
> > > which will tell the kernel that it made a decision and record it.
> > >
> > > It would be used something like this in user space code:
> > > response.response = FAN_DENY | FAN_AUDIT;
> > > write(fd, &response, sizeof(struct fanotify_response));
> > >
> > > When the syscall ends, the audit system will record the decision as a
> > > AUDIT_FANOTIFY auxiliary record to denote that the reason this event
> > > occurred is the result of an access control decision from fanotify
> > > rather than DAC or MAC policy.
> > >
> > > A sample event looks like this:
> > >
> > > type=PATH msg=audit(1504310584.332:290): item=0 name="./evil-ls"
> > > inode=1319561 dev=fc:03 mode=0100755 ouid=1000 ogid=1000 rdev=00:00
> > > obj=unconfined_u:object_r:user_home_t:s0 nametype=NORMAL
> > > type=CWD msg=audit(1504310584.332:290): cwd="/home/sgrubb"
> > > type=SYSCALL msg=audit(1504310584.332:290): arch=c03e syscall=2
> > > success=no exit=-1 a0=32cb3fca90 a1=0 a2=43 a3=8 items=1 ppid=901
> > > pid=959 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
> > > fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="bash"
> > > exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:
> > > s0-s0:c0.c1023 key=(null)
> > > type=FANOTIFY msg=audit(1504310584.332:290): resp=2
> > >
> > > Signed-off-by: sgrubb
> >
> > In the AUDIT_FANOTIFY record, there is a new field "resp". Should this
> > not conform to the existing field types "res" or "result"?
>
> The values used by fanotify are either 1 & 2 rather than 0 & 1. So, it would
> need record specific translation. It's easier to just pick a new field name
> and key off of that.
Ah, fair enough. That's unfortunate.
> -Steve
>
> > Other than that,
> > Reviewed-by: Richard Guy Briggs
> >
> > > ---
> > >
> > > fs/notify/fanotify/fanotify.c | 8 +++-
> > > fs/notify/fanotify/fanotify_user.c | 2 +-
> > > include/linux/audit.h | 7 +++
> > > include/uapi/linux/audit.h | 1 +
> > > include/uapi/linux/fanotify.h | 2 ++
> > > kernel/auditsc.c | 6 ++
> > > 6 files changed, 24 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > > index 2fa99ae..1968d21 100644
> > > --- a/fs/notify/fanotify/fanotify.c
> > > +++ b/fs/notify/fanotify/fanotify.c
> > > @@ -9,6 +9,7 @@
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > +#include
> > >
> > > #include "fanotify.h"
> > >
> > > @@ -78,7 +79,7 @@ static int fanotify_get_response(struct fsnotify_group
> > > *group,>
> > > fsnotify_finish_user_wait(iter_info);
> > >
> > > out:
> > > /* userspace responded, convert to something usable */
> > >
> > > - switch (event->response) {
> > > + switch (event->response & ~FAN_AUDIT) {
> > >
> > > case FAN_ALLOW:
> > > ret = 0;
> > > break;
> > >
> > > @@ -86,6 +87,11 @@ static int fanotify_get_response(struct fsnotify_group
> > > *group,>
> > > default:
> > > ret = -EPERM;
> > >
> > > }
> > >
> > > +
> > > + /* Check if the response should be audited */
> > > + if (event->response & FAN_AUDIT)
> > > + audit_fanotify(event->response & ~FAN_AUDIT);
> > > +
> > >
> > > event->response = 0;
> > >
> > > pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
> > >
> > > diff --git a/fs/notify/fanotify/fanotify_user.c
> > > b/fs/notify/fanotify/fanotify_user.c index 907a481..b983b5c 100644
> > > --- a/fs/notify/fanotify/fanotify_user.c
> > > +++ b/fs/notify/fanotify/fanotify_user.c
> > > @@ -179,7 +179,7 @@ static int process_access_response(struct
> > > fsnotify_group *group,>
> > >* userspace can send a valid response or we will clean it up after the
> > >* timeout
> > >*/
> > >
> > > - switch (response) {
> > > + switch (response & ~FAN_AUDIT) {
> > >
> > > case FAN_ALLOW:
> > >
> > > case FAN_DENY:
> > > break;
> > >
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index 2150bdc..bf55732 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm
> > > *bprm,>
> > > extern void __audit_log_capset(const struct cred *new, const struct cred
> > > *old); extern void __audit_mmap_fd(int fd, int flags);
> > > extern void __audit_log_kern_module(char *name);
> > >
> > > +extern void __audit_fanotify(unsigned int response);
> > >
> > > static
Re: [PATCH 1/1] audit: Record fanotify access control decisions
On Wed 06-09-17 10:35:32, Steve Grubb wrote:
> On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> > On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> > > The fanotify interface allows user space daemons to make access
> > >
> > > control decisions. Under common criteria requirements, we need to
> > > optionally record decisions based on policy. This patch adds a bit mask,
> > > FAN_AUDIT, that a user space daemon can 'or' into the response decision
> > > which will tell the kernel that it made a decision and record it.
> >
> > [Since this is API change, added linux-api to CC, also added Amir since he
> > works with fanotify]
> >
> > Hum, probably I'm missing something here but why an application responding
> > to fanotify event should need to know about audit?
>
> Common Criteria rules are that if anything can prevent a flow of information,
> then you must be able to selectively audit. Selectively audit means under
> admin direction only when they want it. Meaning they may want some denials or
> approvals but not other ones.
OK, thanks for explanation.
> > Or is it that for CCrequirements you have to implement some deamon which
> > will arbitrate access using fanotify and you need to have decisions logged
> > using kernel audit interface?
>
> Yes. And even virus scanners would probably want to allow admins to pick when
> they record something being blocked.
But then if I understand it correctly, you would need to patch each and
every user of fanotify permission events to know about FAN_AUDIT to meet
those CC requirements? That seems pretty hard to do to me and even it done,
it sounds like quite a bit of duplication?
So wouldn't it be better design to pipe all fanotify access decisions to
audit subsystem which would based on policy decide whether the event should
be logged or not? I assume something like this must be working when access
is denied e.g. because of file permissions? And again I appologize for my
total ignorance of how audit works...
> > > +void __audit_fanotify(unsigned int response)
> > > +{
> > > + audit_log(current->audit_context, GFP_ATOMIC,
> > > + AUDIT_FANOTIFY, "resp=%u", response);
> > > +}
> >
> > Heh, GFP_ATOMIC looks pretty crude and it can fail more often than you'd
> > think. In fact fanotify uses GFP_KERNEL for allocation of new event and I
> > don't see a reason why __audit_fanotify() couldn't use the same.
>
> Sure, that's easy enough to change. Is that the only change needed? Is
> the choice of 0x80 for the FAN_AUDIT bit OK? I wanted to leave some room
> for other numbers if there ever was a new use. The number is arbitrary
> and could be anything.
Yeah, 0x80 for FAN_AUDIT is OK. Also Amir's comment about fanotify_init()
flag should be reflected. But I'd really like to understand why design like
this was chosen before merging the change.
Honza
--
Jan Kara
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH 1/1] audit: Record fanotify access control decisions
Hello Jan,
On Wednesday, September 6, 2017 12:48:21 PM EDT Jan Kara wrote:
> On Wed 06-09-17 10:35:32, Steve Grubb wrote:
> > On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> > > Or is it that for CCrequirements you have to implement some deamon which
> > > will arbitrate access using fanotify and you need to have decisions
> > > logged using kernel audit interface?
> >
> > Yes. And even virus scanners would probably want to allow admins to pick
> > when they record something being blocked.
>
> But then if I understand it correctly, you would need to patch each and
> every user of fanotify permission events to know about FAN_AUDIT to meet
> those CC requirements?
Not really. For CC, the mechanism just needs to be available.
> That seems pretty hard to do to me and even it done, it sounds like quite a
> bit of duplication?
AFAIK, there is only one that needs to get patched. It's totally opt in.
> So wouldn't it be better design to pipe all fanotify access decisions to
> audit subsystem which would based on policy decide whether the event should
> be logged or not?
There can be a lot of information to wade through. Normally, we don't parse
events in the kernel or user space. They are in a race to keep events flowing
so that the kernel stays fast and responsive. There are buffer limits where if
we too far behind we start losing events. The decision to log should be rare.
So, if we get lots of events that don't need to be logged, it will slow down
the whole kernel.
But besides the performance side of it, the audit subsystem has part of the
information to make a decision on whether or not this one should be logged. It
doesn't know the same information as the daemon that is deciding to grant
access. Only the daemon granting access knows if this one file alone should
get an audit record. And based on the fanotify API there is no way to pass
along additional information that could be taken into account by the audit
subsystem for its decision.
> I assume something like this must be working when access
> is denied e.g. because of file permissions? And again I appologize for my
> total ignorance of how audit works...
We have control over that, too. You can audit all EPERM events or you can be
selective about getting them from a specific directory, application, user, or
MAC label. To get this kind of granularity would mean making another filter in
the kernel and loading a set of rules which duplicates, for the most part, the
rules the access daemon has. Then we'd still need the identifier saying the
event originated from the fanotify subsystem. This leads to a lot more
complexity.
As it stands, the patch set adds 24 lines of code. So, its much more
minimalistic and places the decision in the only thing that truly knows if an
event is needed. But let's examine that a bit.
The user space daemon could also directly log an event through the user space
API. But, it would need to gather a lot of information to fully identify the
subject and objects in the event. There is a size limit on how big an event
could be. So, if we have a file that is at PATH_MAX and has control characters
in it, we would need 8192 bytes to log the filename. Add in the MAC labels and
other house keeping and we have less than 100 bytes to log information.
This also means we need to make new parsers and design reporting to make sense
of this new record format. So, due to these size limits, it more robust to
generate the record in the kernel and coopt all the reporting mechanisms that
are already in place.
So, to sum it up, doing it this was is better performance for the kernel, only
needs 24 or so additional lines of code in the kernel, only 4 lines in the
user space daemon, and 4 lines in the user space audit code. Its the simplest
approach with the best targeting of events.
Does this help?
> > > > +void __audit_fanotify(unsigned int response)
> > > > +{
> > > > + audit_log(current->audit_context, GFP_ATOMIC,
> > > > + AUDIT_FANOTIFY, "resp=%u", response);
> > > > +}
> > >
> > > Heh, GFP_ATOMIC looks pretty crude and it can fail more often than you'd
> > > think. In fact fanotify uses GFP_KERNEL for allocation of new event and
> > > I don't see a reason why __audit_fanotify() couldn't use the same.
> >
> > Sure, that's easy enough to change. Is that the only change needed? Is
> > the choice of 0x80 for the FAN_AUDIT bit OK? I wanted to leave some room
> > for other numbers if there ever was a new use. The number is arbitrary
> > and could be anything.
>
> Yeah, 0x80 for FAN_AUDIT is OK. Also Amir's comment about fanotify_init()
> flag should be reflected. But I'd really like to understand why design like
> this was chosen before merging the change.
Sure. I'll add that into v2 of the patch.
Thanks,
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: Auditing console access
On Wednesday, September 6, 2017 9:42:53 AM EDT Maupertuis Philippe wrote: > Hi, > The examples found in the audit documentation mention that to work it is > assumed that no direct root login is allowed. This very sensible and not a > big problem except for console access. Why is it a problem for console access? :-) > What would be the best way to monitor what is done through this access ? If you need to know the commands & changes made by root, then you probably need to use pam_tty_audit to enable tty auditing for su and sudo. > Would you recommend to forbid root access even in console ? Yes. Who is root? Who was root 4 years ago? By logging in with your account and then changing to root, the audit system can track who root is. The only time I can think of where you wouldn't want this tracking is when the system is in single user mode. (Because auditd doesn't normally start in single user mode.) -Steve > !!!* > "Ce message et les pi?ces jointes sont confidentiels et > r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre > prot?g? par le secret professionnel. Si vous recevez ce message par erreur, > merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. > L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la > responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de > ce message. Bien que les meilleurs efforts soient faits pour maintenir > cette transmission exempte de tout virus, l'exp?diteur ne donne aucune > garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour > tout dommage r?sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its > integrity cannot be secured on the Internet, the Worldline liability cannot > be triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!" -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
