Re: [PATCH] Don't crash on unknown S_IFMT file modes
by Miloslav Trmac
----- "LC Bruzenak" <lenny(a)magitekltd.com> wrote:
> Thank you for this patch...wherever it may be.
> :)
Ooops :/
> Do you have a standard auparse test you use to track these down?
No, I only have a small Python program to use auparse to interpret a supplied log file (attached). There is also (make check).
Mirek
15 years, 9 months
Re: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)
by KaiGai Kohei
Matthew Booth wrote:
> KaiGai Kohei wrote:
>> Hello,
>>
>> I'm a developer of SE-PostgreSQL which is an enhancement of
>> database security using SELinux. It enables to apply the
>> security policy of the operating system on accesses to
>> database objects also.
>> It makes an access control decision and audit messages, but
>> these are not written out to system audit mechanism.
>>
>> I believe our preferable behavior is the system audit collects
>> all the audit messages come from SELinux, not a logfile of
>> PostgreSQL.
>>
>> Currently, the audit-libs has an interface to write a message
>> come from userspace avc, but some of parameter is not suitable
>> for the reference monitor in database management system.
>>
>> This patch adds a new interface as follows:
>> int audit_log_database_message(int audit_fd, int type,
>> const char *message,
>> const char *hostname,
>> const char *addr,
>> const char *dbuser);
>>
>> It is differ from audit_log_user_avc_message() in the point of
>> a new parameter of dbuser, instead of tty and uid.
>> I don't think these are meaningful information for DBMS, but
>> we would like to record what database user invokes this audit
>> record.
>
> A few points:
>
> When I have tried to use this mechanism in the past I have found the
> existing proliferation of user messages types confusing. If possible,
> please don't add a new custom message to the library. Instead, maybe it
> would be better to recognise that there will be continue to be new and
> unanticipated uses for structured audit data, and provide an api which
> allows that to be expressed.
What I would like to audit is AUDIT_USER_AVC type message, not a new
custome message type. But the current interface does not allow to
record some of meaningful information.
So, it was necessary to propose a new audit_log_database_message().
Perhaps, it might be misnamed. If confusable, it is possible to rename
it something like audit_log_db_avc_message().
> While where may be no tty as such, the idea is still meaningful.
> Specifically, one of the first things an auditor will want to know is
> where the user who performed a particular action logged on from. If you
> have that information, you should include it in the audit record.
In this case, all the audit record has same tty which is used by
the server process, independent from the client who performed a
particular action. :(
> A concept of a session ID would probably have meaning in this context.
> If you have one, or can create one, please include it in all messages,
> including login messages.
When a database client connects to the server via TCP/IP, we don't have
any valid session id. In addition, the server does not have a method to
know what session id is used for the client logged in.
> Lastly, please no freeform text! It should be possible to determine
> everything relevant about an event without looking at freeform text.
Yes, the expected style is same as ones for audit_log_user_avc_message(),
without any freedom text. The most significant purpose is to allow users
to use utilities such as audit2allow.
> I look forward to playing with this :)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
15 years, 9 months
[PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)
by KaiGai Kohei
Hello,
I'm a developer of SE-PostgreSQL which is an enhancement of
database security using SELinux. It enables to apply the
security policy of the operating system on accesses to
database objects also.
It makes an access control decision and audit messages, but
these are not written out to system audit mechanism.
I believe our preferable behavior is the system audit collects
all the audit messages come from SELinux, not a logfile of
PostgreSQL.
Currently, the audit-libs has an interface to write a message
come from userspace avc, but some of parameter is not suitable
for the reference monitor in database management system.
This patch adds a new interface as follows:
int audit_log_database_message(int audit_fd, int type,
const char *message,
const char *hostname,
const char *addr,
const char *dbuser);
It is differ from audit_log_user_avc_message() in the point of
a new parameter of dbuser, instead of tty and uid.
I don't think these are meaningful information for DBMS, but
we would like to record what database user invokes this audit
record.
Please any comments.
Thanks,
KaiGai Kohei wrote:
> 2. System audit integration
>
> Now, SE-PostgreSQL writes out its access denied message into
> the logfile of PostgreSQL (/var/log/sepostgresql.log).
> But it is more desirable approach to write out them into system
> audit mechanism, because any other SELinux related messages
> are collected here and utilities like audit2allow is available.
>
> TODO:
> - changes in the security policy:
> We need to allow postgresql_t to write audit messages.
> In addition, the backend process need to run with cap_audit_write.
>
> - a new interface in audit-libs:
> The current audit-libs has the following interface.
>
> extern int audit_log_user_avc_message(int audit_fd, int type,
> const char *message, const char *hostname, const char *addr,
> const char *tty, uid_t uid);
>
> But some arguments are not meaningful in SE-PostgreSQL.
> I would like to write out database role here, instead of tty and uid.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
15 years, 9 months
Re: [PATCH] Add SELinux context and TTY name to AUDIT_TTY records
by Miloslav Trmac
Paul,
Thanks for your review.
----- "Paul Moore" <paul.moore(a)hp.com> wrote:
> There are several audit experts which should review this code but two
> things
> jumped out at me when glancing at your patch:
>
> 1. SELinux SIDs should not be recorded
Almost all code that logs SELinux contexts in kernel/audit* does the same thing as this patch, falling back to a SID if it can't be converted to a string.
> 2. From a SELinux/security point of view ttys are considered objects
> and their labels/contexts should be recorded with "obj=" not
> "subj="
The patch logs the context of the process, not of the TTY.
Mirek
15 years, 9 months
[PATCH] Add SELinux context and TTY name to AUDIT_TTY records
by Miloslav Trmac
From: Miloslav Trmač <mitr(a)redhat.com>
Add SELinux context information and TTY name (consistent with the
AUDIT_SYSCALL record) to AUDIT_TTY. An example record after applying
this patch:
type=TTY msg=audit(1237480806.220:22): tty pid=2601 uid=0 auid=500 ses=1
subj=unconfined_u:unconfined_r:unconfined_t:s0 major=136 minor=1 tty=pts1
comm="bash" data=6361740D
(line wrapped, new fields are "subj" and "tty".)
Signed-off-by: Miloslav Trmač <mitr(a)redhat.com>
---
drivers/char/tty_audit.c | 57 ++++++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 19 deletions(-)
15 years, 9 months
Multiple EXECVE records
by Matthew Booth
Any idea what this means:
type=SYSCALL msg=audit(1236769790.766:247): arch=40000003 syscall=11
success=yes exit=0 a0=9d1e668 a1=9d23e50 a2
type=EXECVE msg=audit(1236769790.766:247): argc=4 a0="/bin/sh"
a1="/sbin/service" a2="sshd" a3="restart"
type=EXECVE msg=audit(1236769790.766:247): argc=3 a0="/bin/sh"
a1="/sbin/service" a2="sshd"
type=CWD msg=audit(1236769790.766:247): cwd="/root"
type=PATH msg=audit(1236769790.766:247): item=0 name="/sbin/service"
inode=189083 dev=fc:01 mode=0100755 ouid=0
type=PATH msg=audit(1236769790.766:247): item=1 name=(null) inode=251907
dev=fc:01 mode=0100755 ouid=0 ogid=0 rd
type=PATH msg=audit(1236769790.766:247): item=2 name=(null) inode=315525
dev=fc:01 mode=0100755 ouid=0 ogid=0 rd
Note that there are 2 EXECVE records there. This was generated by RHEL
5.3 i386.
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
15 years, 9 months
A change to string encoding
by Matthew Booth
The problem with current string encoding is that it is parsable, but
non-human readable. It also complicates parsing by requiring 2 different
decoding methods to be implemented.
It occurs to me that a URL encoding scheme would also meet the parsing
requirements. Additionally:
1. It is always human readable.
2. There is only 1 encoding scheme.
3. Substring matching on encoded strings will always succeed.
URL encoding is just one way to achieve this, and has the advantage of
being widely implemented. However, the minimal requirements would be a
scheme which encoded only separator characters (whitespace in this case)
without the use of those separators.
I'm sure this has been considered before. Given that it's a road I'm
considering heading down, what were the reasons for not doing it?
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
15 years, 9 months
Differentiating user activity from system activity
by Matthew Booth
In the broadest possible sense, including definitions of 'user activity'
and 'system activity', what schemes have people considered for the
above?
On other unixes, audit events have an associated 'terminal'. On the face
of it, this seems like a reasonable differentiator. I.e. a 'user'
process has a terminal, a 'system' process does not. Is this any good?
On Linux we don't record a terminal. How about a non-default auid? What
about system daemons restarted by an administrator? How about SELinux?
Your thoughts appreciated,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
15 years, 9 months
integrity: audit
by Mimi Zohar
The original patch added support to auditd for integrity messages, which
are issued as a result of the integrity patchset that was applied to the
security-testing-2.6/#next tree.
This patch adds support for the new AUDIT_INTEGRITY_RULE message.
Signed-off-by: Mimi Zohar <zohar(a)us.ibm.com>
Index: audit-1.7.11/src/ausearch-parse.c
===================================================================
--- audit-1.7.11.orig/src/ausearch-parse.c
+++ audit-1.7.11/src/ausearch-parse.c
@@ -49,6 +49,7 @@ static int parse_login(const lnode *n, s
static int parse_daemon(const lnode *n, search_items *s);
static int parse_sockaddr(const lnode *n, search_items *s);
static int parse_avc(const lnode *n, search_items *s);
+static int parse_integrity(const lnode *n, search_items *s);
static int parse_kernel_anom(const lnode *n, search_items *s);
static int parse_simple_message(const lnode *n, search_items *s);
static int parse_tty(const lnode *n, search_items *s);
@@ -123,6 +124,9 @@ int extract_search_items(llist *l)
case AUDIT_MAC_POLICY_LOAD...AUDIT_MAC_UNLBL_STCDEL:
ret = parse_simple_message(n, s);
break;
+ case AUDIT_INTEGRITY_DATA...AUDIT_INTEGRITY_RULE:
+ ret = parse_integrity(n, s);
+ break;
case AUDIT_KERNEL:
case AUDIT_IPC:
case AUDIT_SELINUX_ERR:
@@ -1150,6 +1154,98 @@ static int parse_sockaddr(const lnode *n
return 0;
}
+static int parse_integrity(const lnode *n, search_items *s)
+{
+ char *ptr, *str, *term;
+ int rc=0;
+
+ term = n->message;
+ // get pid
+ str = strstr(term, "pid=");
+ if (str) {
+ ptr = str + 4;
+ term = strchr(ptr, ' ');
+ if (term == NULL)
+ return 2;
+ *term = 0;
+ errno = 0;
+ s->pid = strtoul(ptr, NULL, 10);
+ if (errno)
+ return 3;
+ *term = ' ';
+ }
+
+ // get uid
+ str = strstr(term, " uid=");
+ if (str) {
+ ptr = str + 4;
+ term = strchr(ptr, ' ');
+ if (term == NULL)
+ return 4;
+ *term = 0;
+ errno = 0;
+ s->uid = strtoul(ptr, NULL, 10);
+ if (errno)
+ return 5;
+ *term = ' ';
+ }
+
+ // get loginuid
+ str = strstr(n->message, "auid=");
+ if (str) {
+ ptr = str + 5;
+ term = strchr(ptr, ' ');
+ if (term == NULL)
+ return 6;
+ *term = 0;
+ errno = 0;
+ s->loginuid = strtoul(ptr, NULL, 10);
+ if (errno)
+ return 7;
+ *term = ' ';
+ }
+
+ str = strstr(term, "comm=");
+ if (str) {
+ str += 5;
+ if (*str == '"') {
+ str++;
+ term = strchr(str, '"');
+ if (term == NULL)
+ return 8;
+ *term = 0;
+ s->comm = strdup(str);
+ *term = '"';
+ } else
+ s->comm = unescape(str);
+ }
+
+ str = strstr(term, " name=");
+ if (str) {
+ str += 6;
+ if (common_path_parser(s, str))
+ return 9;
+ }
+
+ // and results (usually last)
+ str = strstr(term, "res=");
+ if (str != NULL) {
+ ptr = str + 4;
+ term = strchr(ptr, ' ');
+ if (term)
+ *term = 0;
+ errno = 0;
+ s->success = strtoul(ptr, NULL, 10);
+ if (errno)
+ return 10;
+ if (term)
+ *term = ' ';
+ }
+
+ return 0;
+}
+
+
/* FIXME: If they are in permissive mode or hit an auditallow, there can
* be more that 1 avc in the same syscall. For now, we pickup just the first.
*/
Index: audit-1.7.11/lib/libaudit.h
===================================================================
--- audit-1.7.11.orig/lib/libaudit.h
+++ audit-1.7.11/lib/libaudit.h
@@ -174,6 +174,12 @@ extern "C" {
#ifndef AUDIT_ANOM_ABEND
#define AUDIT_ANOM_ABEND 1701 /* Process ended abnormally */
#endif
+#define AUDIT_INTEGRITY_DATA 1800 /* Data integrity verification */
+#define AUDIT_INTEGRITY_METADATA 1801 /* Metadata integrity verification */
+#define AUDIT_INTEGRITY_STATUS 1802 /* Integrity enable status */
+#define AUDIT_INTEGRITY_HASH 1803 /* Integrity HASH type */
+#define AUDIT_INTEGRITY_PCR 1804 /* PCR invalidation msgs */
+#define AUDIT_INTEGRITY_RULE 1805 /* Policy rule */
#define AUDIT_FIRST_ANOM_MSG 2100
#define AUDIT_LAST_ANOM_MSG 2199
#define AUDIT_ANOM_LOGIN_FAILURES 2100 // Failed login limit reached
Index: audit-1.7.11/lib/msg_typetab.h
===================================================================
--- audit-1.7.11.orig/lib/msg_typetab.h
+++ audit-1.7.11/lib/msg_typetab.h
@@ -122,6 +122,13 @@ _S(AUDIT_MAC_UNLBL_STCADD, "MA
_S(AUDIT_MAC_UNLBL_STCDEL, "MAC_UNLBL_STCDEL" )
_S(AUDIT_ANOM_PROMISCUOUS, "ANOM_PROMISCUOUS" )
_S(AUDIT_ANOM_ABEND, "ANOM_ABEND" )
+_S(AUDIT_INTEGRITY_DATA, "INTEGRITY_DATA" )
+_S(AUDIT_INTEGRITY_METADATA, "INTEGRITY_METADATA" )
+_S(AUDIT_INTEGRITY_STATUS, "INTEGRITY_STATUS" )
+_S(AUDIT_INTEGRITY_HASH, "INTEGRITY_HASH" )
+_S(AUDIT_INTEGRITY_PCR, "INTEGRITY_PCR" )
+_S(AUDIT_INTEGRITY_RULE, "INTEGRITY_RULE" )
+
#ifdef WITH_APPARMOR
_S(AUDIT_AA, "APPARMOR" )
_S(AUDIT_APPARMOR_AUDIT, "APPARMOR_AUDIT" )
Index: audit-1.7.11/system-config-audit/src/lists.py
===================================================================
--- audit-1.7.11.orig/system-config-audit/src/lists.py
+++ audit-1.7.11/system-config-audit/src/lists.py
@@ -160,6 +160,12 @@ audit.AUDIT_LAST_KERN_ANOM_MSG,
audit.AUDIT_ANOM_PROMISCUOUS,
audit.AUDIT_ANOM_ABEND,
audit.AUDIT_KERNEL,
+audit.AUDIT_INTEGRITY_DATA,
+audit.AUDIT_INTEGRITY_METADATA,
+audit.AUDIT_INTEGRITY_STATUS,
+audit.AUDIT_INTEGRITY_HASH,
+audit.AUDIT_INTEGRITY_PCR,
+audit.AUDIT_INTEGRITY_RULE,
)
# From code in src/auditctl.c
Index: audit-1.7.11/lib/netlink.c
===================================================================
--- audit-1.7.11.orig/lib/netlink.c
+++ audit-1.7.11/lib/netlink.c
@@ -182,7 +182,8 @@ static int adjust_reply(struct audit_rep
case AUDIT_FIRST_USER_MSG...AUDIT_LAST_USER_MSG:
case AUDIT_FIRST_USER_MSG2...AUDIT_LAST_USER_MSG2:
case AUDIT_FIRST_EVENT...AUDIT_LAST_KERN_ANOM_MSG:
- rep->message = NLMSG_DATA(rep->nlh);
+ case AUDIT_INTEGRITY_DATA...AUDIT_INTEGRITY_RULE:
+ rep->message = NLMSG_DATA(rep->nlh);
break;
case AUDIT_SIGNAL_INFO:
rep->signal_info = NLMSG_DATA(rep->nlh);
15 years, 9 months
