3:46 p.m.
Hello,
The way that the watch list is passed back currently is a string. This
diminishes its usefullness. The way it should really be passed back is in a
structure. This allows each part to have meaning (without parsing) and be
formatted in userspace as needed. The only problem is the structure is
defined as follows:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char *name;
char *filterkey;
uint32_t perms;
};
name and filterkey are pointers. If we changed the structure to this:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char name[MAX_PATH];
char filterkey[MAX_KEY_LEN];
uint32_t perms;
};
Then the structure can be used bi-directionally. Which brings up another
point...when the watch is being sent into the kernel, what guarantee do we
have that the app doesn't dissappear by the time the netlink packet is
dispositioned and the pointers dereferenced?
-Steve
4:36 p.m.
On Monday 04 April 2005 03:46 pm, Steve Grubb wrote:
Hello,
The way that the watch list is passed back currently is a string. This
diminishes its usefullness. The way it should really be passed back is in a
structure. This allows each part to have meaning (without parsing) and be
formatted in userspace as needed. The only problem is the structure is
defined as follows:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char *name;
char *filterkey;
uint32_t perms;
};
name and filterkey are pointers. If we changed the structure to this:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char name[MAX_PATH];
char filterkey[MAX_KEY_LEN];
uint32_t perms;
};
Then the structure can be used bi-directionally. Which brings up another
point...when the watch is being sent into the kernel, what guarantee do we
have that the app doesn't dissappear by the time the netlink packet is
dispositioned and the pointers dereferenced?
Yes, I intended to address this later this week. However, I do not plan on
passing them to and from the kernel as structures, but as a serialized
strings.
Also, I wouldn't recommend wasting so much space by statically allocating 4096
(or whatever MAX_PATH happens to be) for each name... considering any file
we're interested in auditing is unlikely to be MAX_PATH or even close to
MAX_PATH. Space is more valuable in the kernel, both on the stack and in
memory, then it is in user space.
And the memory should already be copied into the kernel by the time the
process ends.
-tim
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
4:50 p.m.
On Monday 04 April 2005 17:36, Timothy R. Chavez wrote:
However, I do not plan on passing them to and from the kernel as
structures,
but as a serialized strings.
Its in the kernel as pieces, why not just fill in the structure and send it to
user space? That has to be simpler to code (3 assignments & 2 strcpy's). Why
invent yet another way to pass data?
Also, I wouldn't recommend wasting so much space by statically
allocating
4096 (or whatever MAX_PATH happens to be) for each name... considering any
file we're interested in auditing is unlikely to be MAX_PATH or even close
to MAX_PATH. Space is more valuable in the kernel, both on the stack and
in memory, then it is in user space.
Right, but this is just for transit. Once inside the kernel it can be put into
a memory area that is as long as strlen - which is what's done currently.
And the memory should already be copied into the kernel by the time
the
process ends.
What guarantees that? netlink receive is asynchronous.
-Steve
5:03 p.m.
On Monday 04 April 2005 04:50 pm, Steve Grubb wrote:
<snip>
> Also, I wouldn't recommend wasting so much space by statically allocating
> 4096 (or whatever MAX_PATH happens to be) for each name... considering
> any file we're interested in auditing is unlikely to be MAX_PATH or even
> close to MAX_PATH. Space is more valuable in the kernel, both on the
> stack and in memory, then it is in user space.
Right, but this is just for transit. Once inside the kernel it can be put
into a memory area that is as long as strlen - which is what's done
currently.
Sure, this would require two seperate structures. I'll do this.
> And the memory should already be copied into the kernel by the time the
> process ends.
What guarantees that? netlink receive is asynchronous.
I suppose we should be waiting for a reply from the kernel. Anyway, if we
want to go the static structure approach, that's fine. I'll work on that
this week and we'll discuss the list feature a little more too.
-tim
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
8:16 a.m.
On Mon, 2005-04-04 at 16:46 -0400, Steve Grubb wrote:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char name[MAX_PATH];
char filterkey[MAX_KEY_LEN];
uint32_t perms;
};
Then the structure can be used bi-directionally. Which brings up another
point...when the watch is being sent into the kernel, what guarantee do we
have that the app doesn't dissappear by the time the netlink packet is
dispositioned and the pointers dereferenced?
The structure could just define the length and perms fields, then put a
char buf[0]; at the end to allow referencing of watch->buf, and just
include the two strings immediately after the structure when creating
it. Kernel can then extract them appropriately based on the lengths.
No need to reserve fixed size fields for them.
BTW, using separate structures for the kernel-userspace interface versus
internal use is a good idea; it lets you evolve the internals without
creating userspace compatibility problems.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
9:27 a.m.
On Tuesday 05 April 2005 09:16, Stephen Smalley wrote:
The structure could just define the length and perms fields, then put
a
char buf[0]; at the end to allow referencing of watch->buf, and just
include the two strings immediately after the structure when creating
it
I can use this technique, too. I just want to make sure that 1) strings are
sent into kernel inside netlink packet so there's no race. 2) When userspace
receives a watch list, it comes in a format that needs no parsing.
-Steve
7200
days inactive
7201
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
Stephen Smalley -
Steve Grubb -
Timothy R. Chavez