11:03 a.m.
On Monday, January 20, 2014 11:44:49 AM Eric Paris wrote:
I think this just touches the surface of what be/have been done.
There
appears to be no logic, consistency, or predictability to audit logs.
Kernel maintainers have not added all the fields I have asked for at some
points. I think it was proposed to add a syscall record to everything which I
absolutely do not want to see. that is too much information.
They are a piecemeal mish mash of information. Every record has
whatever fields it has, not because there is some coherent reason, but
because that's what somebody accidentally put in there when the record
was created.
What is required is this:
1) when it happened
2) who did it
3) what did they act upon
4) what did they do
5) what was the result
#1 is done automatically.
#2 depends on which API the action occurred on and if we have a MAC subsystem
or not. For netlink, we are limited to what rides along in the skb. For the
syscall interface, we have everything. For actions through /proc, we probably
can have everything. Then there are various events embedded in the kernel
like the IMA events which trigger when they get loaded. So, what is necessary
to identify the subject? In descending order of importance: auid, uid, ses,
tty, pid, subj, exe, comm, euid, gid, egid, everything else.
#3 is usually given by auxiliary records such as PATH, OBJ_PID, EXECVE, etc.
They should include fields that make it possible to know exactly what was acted
upon such as device, inode, ownership/group, permissions, object labels, or
whatever it takes to know what was being manipulated depending on what it
actually is.
#4 is given by the event type. In cases where the event type is multiplexed,
we need a op= field to say what operation is being performed. This is trusted
information and never under attacker control and should never be logged as an
untrusted string. In cases where there might be a space between words, just
convert the space to a dash.
#5 This is a simple res= field.
That said...whatever we have right now, the audit utilities looks for that and
only that. If we suddenly added a bunch of new fields, I still have to support
all the mistakes of the past. The 2.x user space audit code supports all
kernels since 2.6.16. Because there is no way to tell when features got added
to what kernels, it will always have to support the whole mess. All of it.
With or without the (proposed) new fields present.
This is a great example. The only things we log are the pid and
uid.
The information in the uid field is actually useless (given the
uid==new-auid but anyway) but clearly for searching reasons it makes
sense. But, why is pid and uid enough? Why not selinux context? Why
not ppid? Why not all of the *id's (gid, fsuid, etc.) Why not comm?
why not tty?
Because kernel maintainers didn't add it.
What is the minimal set of information we should be sending with
every
record that uniquely identifies a process? Why is every record it's own
little world?
To save disk space. That is paramount. We cannot add syscall to everything
without eating up a lot of disk space. The main thing to remember is that
people who really use auditing never have enough disk space to keep everything
they want. So, we should always consider doing anything possible to minimize
disk usage no matter what.
I know we grew organically to get here, but I'd really
like to find a consistent usable future...
Maybe we don't need everything from a syscall record in every record,
but there is some meaningful subset which identifies a process and user.
What is that subset?
See above.
HTH...
-Steve
On Fri, 2014-01-17 at 18:34 -0500, Richard Guy Briggs wrote:
> I missed posting this before the holidays. I discovered this while adding
> other information to other message types.
>
> It seemed to me that loginuid changes were significantly missing context
> references. This patch adds that. Is this sufficient, or is there more
> information missing too? If this is sufficient, stop reading this cover
> letter and review the patch. If it is not sufficient, keep reading
> below...
>
> The question has been raised that perhaps we should be switching this to
> use audit_log_task_info() istead which adds a whole lot more information
> about this task.
>
> In the existing message
>
> pid
> uid
>
> are already given, before
>
> old-auid
> new-auid
> old-ses
> new-ses
>
> .
>
> The function audit_log_task_info() gives:
> ppid
> pid
> auid
> uid
> gid
> euid
> suid
> fsuid
> egid
> sgid
> fsgid
> tty
> ses
>
> comm
>
> exe
> res
>
> .
>
> So,
>
> pid
> uid
>
> are in the right order, along with
>
> new-auid (auid)
> new-ses (ses)
>
> but if we give the
>
> old-auid
> old-ses
>
> values first, then call audit_log_task_info(), the old values will preceed
>
> pid
> uid
>
> .
>
> Is this re-ordering acceptable to gain more information and reduce code
> duplicity?>
> Richard Guy Briggs (1):
> audit: log task context when setting loginuid
>
> kernel/auditsc.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)