It's nice to check for consistency though, so we're adding that. Profile
loading is a trusted operation, at least so far, and so security wise we
don't actually have to care --- if loading an invalid profile can bring down
the system, then that's no worse than an arbitrary module that
On Mon, Apr 16, 2007 at 08:27:08AM +0200, Andi Kleen wrote:
It's nice to check for consistency though, so we're adding that. Profile
loading is a trusted operation, at least so far, and so security wise we
don't actually have to care --- if loading an invalid profile can bring
down
don't actually have to care --- if loading an invalid profile can bring down
the system, then that's no worse than an arbitrary module that crashes the
machine. Not sure if there will ever be user loadable profiles; at least at
that point we had to care.
CAP_SYS_RAWIO is needed to do
On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote:
don't actually have to care --- if loading an invalid profile can bring
down
the system, then that's no worse than an arbitrary module that crashes the
machine. Not sure if there will ever be user loadable profiles; at least at
Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen [EMAIL PROTECTED]
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
---
security/apparmor/match.c| 232
security/apparmor/match.h| 83
+ th.td_id = ntohs(*(u16 *) (blob));
+ th.td_flags = ntohs(*(u16 *) (blob + 2));
+ th.td_lolen = ntohl(*(u32 *) (blob + 8));
Use cpu_to and _to_cpu functions for here so it is clear the intended
direction and endianness.
+
+static inline int aa_inbounds(struct aa_ext *e, size_t
[EMAIL PROTECTED] writes:
[didn't review code fully, just some stuff I noticed]
+
+struct aa_dfa {
+ struct table_header *tables[YYTD_ID_NXT];
+};
If that is passed in from user space you would need special compat
code for 64bit kernels who support 32bit userland.
Better to avoid
