On Mon, Jul 11, 2005 at 11:07:17AM -0500, Michael C Thompson wrote:
> > > Ultimately, the part where we differ most, is the processing of
> > > information in
> > > fs/dcache.c to give dynamic updates in response to file system activity
> > > (such
> > > as attaching audit information to an audit
On Fri, Jul 08, 2005 at 02:48:03PM -0500, Timothy R. Chavez wrote:
> I've chosen not to respond to individual segments because the overall theme
> is that the right thing to do is to not duplicate functionality.
Correct.
> Your suggestion is to merge the two projects.
Or at the minimal, the comm
On 7/8/05, Chris Wright <[EMAIL PROTECTED]> wrote:
> * Timothy R. Chavez ([EMAIL PROTECTED]) wrote:
> > @@ -69,6 +70,8 @@ int inode_setattr(struct inode * inode,
> > unsigned int ia_valid = attr->ia_valid;
> > int error = 0;
> >
> > + audit_notify_watch(inode, MAY_WRITE);
> > +
>
>
* Timothy R. Chavez ([EMAIL PROTECTED]) wrote:
> @@ -69,6 +70,8 @@ int inode_setattr(struct inode * inode,
> unsigned int ia_valid = attr->ia_valid;
> int error = 0;
>
> + audit_notify_watch(inode, MAY_WRITE);
> +
Hmm, this looks wrong. It should be in notify_change, since I
On Friday 08 July 2005 12:46, Greg KH wrote:
> On Thu, Jul 07, 2005 at 02:49:15PM -0500, Timothy R. Chavez wrote:
> >
> > Even if access control prohibits us from actually seeing the content of
> > /etc/shadow, if we're auditing /etc/shadow, attempts should be logged
> > and not gone unnoticed.
On Thu, Jul 07, 2005 at 02:49:15PM -0500, Timothy R. Chavez wrote:
>
> Even if access control prohibits us from actually seeing the content of
> /etc/shadow, if we're auditing /etc/shadow, attempts should be logged
> and not gone unnoticed.
>
> watch /etc/shadow
> passwd
>
> cat /etc/shadow (g
On Thu, Jul 07, 2005 at 03:48:37PM -0400, Steve Grubb wrote:
> On Thursday 07 July 2005 15:04, Greg KH wrote:
> > You are adding auditfs, a new userspace access, right?
>
> Not sure what you mean. This is using the same netlink interface that all the
> rest of the audit system is using for comman
On Fri, 8 Jul 2005, Arjan van de Ven wrote:
> why not?
> If your /etc/shadow has no selinux context you've lost already :0
No, the kernel will map it to something safe.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
> > [EMAIL PROTECTED] /]$ cat /etc/shadow
> > cat: /etc/shadow: Permission denied
>
> Additionally, the apps would need to either be rewritten to create
> the files under the audited context, or policy would have to cause all
> files created by those apps to be under the audited context. Neither
Quoting Timothy R. Chavez ([EMAIL PROTECTED]):
> On Thursday 07 July 2005 16:31, Arjan van de Ven wrote:
> > On Thu, 2005-07-07 at 15:48 -0400, Steve Grubb wrote:
> >
> > > Tim's code lets you say I want change notification to this file only. The
> > > notification follows the audit format with a
On Thu, 2005-07-07 at 15:48 -0400, Steve Grubb wrote:
> Tim's code lets you say I want change notification to this file only. The
> notification follows the audit format with all relavant pieces of information
> gathered at the time of the event and serialized with all other events.
well can't
On Thursday 07 July 2005 16:31, Arjan van de Ven wrote:
> On Thu, 2005-07-07 at 15:48 -0400, Steve Grubb wrote:
>
> > Tim's code lets you say I want change notification to this file only. The
> > notification follows the audit format with all relavant pieces of
> > information
> > gathered at t
On Thursday 07 July 2005 15:04, Greg KH wrote:
> You are adding auditfs, a new userspace access, right?
Not sure what you mean. This is using the same netlink interface that all the
rest of the audit system is using for command and control. Nothing has
changed here. What is different is the mess
On Thursday 07 July 2005 13:10, Greg KH wrote:
> On Thu, Jul 07, 2005 at 11:26:51AM -0500, Timothy R. Chavez wrote:
> > On Wednesday 06 July 2005 18:50, Greg KH wrote:
> > > On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> > > > This is similar to Inotify in that the audit subsy
On Thu, Jul 07, 2005 at 02:49:09PM -0400, Steve Grubb wrote:
> On Thursday 07 July 2005 14:15, Greg KH wrote:
> > I fail to see any refactoring here, why not make your patch rely on
> > theirs?
>
> At the time this code was developed, inotify was not in the kernel. We would
> be patching against
On Thursday 07 July 2005 14:15, Greg KH wrote:
> I fail to see any refactoring here, why not make your patch rely on
> theirs?
At the time this code was developed, inotify was not in the kernel. We would
be patching against another patch that's not in the kernel.
> > The whole rest of it is diff
On Thu, Jul 07, 2005 at 07:16:35PM +0100, David Woodhouse wrote:
> On Thu, 2005-07-07 at 11:10 -0700, Greg KH wrote:
> > Yes, and then I change namespaces to put /etc/shadow at
> > /foo/baz/etc/shadow and then access it that way? Will the current
> > audit system fail to catch that access?
>
> Th
On Thu, 2005-07-07 at 11:10 -0700, Greg KH wrote:
> Yes, and then I change namespaces to put /etc/shadow at
> /foo/baz/etc/shadow and then access it that way? Will the current
> audit system fail to catch that access?
The watch is attached to the inode which you happened to call '/etc' in
your na
On Wed, Jul 06, 2005 at 09:33:05PM -0400, Steve Grubb wrote:
> On Wednesday 06 July 2005 19:50, Greg KH wrote:
> > As inotify works off of open file descriptors, yes, this is true. ?But,
> > again, if you think this is really important, then why not just work
> > with inotify to provide that kind o
On Thu, Jul 07, 2005 at 11:26:51AM -0500, Timothy R. Chavez wrote:
> On Wednesday 06 July 2005 18:50, Greg KH wrote:
> > On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> > > This is similar to Inotify in that the audit subsystem watches for file
> > > system activity and collect
On Wednesday 06 July 2005 18:50, Greg KH wrote:
> On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> > This is similar to Inotify in that the audit subsystem watches for file
> > system activity and collects information about inodes its interested
> > in, but this is where the si
On Thu, 2005-07-07 at 08:40 +0200, Arjan van de Ven wrote:
> why is this? It would be a very logical thing to store this stuff inside
> the inode. It sounds like a bad design to keep per inode data out of the
> inode. (if you're concerned about taking a lot of space, put a pointer
> to a kmalloc()'
>
> Some notable implementation details are as follows:
>
> * struct inode is _not_ extended to associate audit data with the
> inode. A hash table is used in which the inode is hashed to
> retrieve its audit data. We know if an inode has audit data
> if I_AUDIT has been turned
Hello,
This patch augments the audit subsystem and VFS to support file system
auditing in which an object is audited based on its location and name.
Depending on the administrator's requirement, this feature can be used
standalone or in conjunction with the (device,inode)-based filters. The
On Wednesday 06 July 2005 19:50, Greg KH wrote:
> As inotify works off of open file descriptors, yes, this is true. But,
> again, if you think this is really important, then why not just work
> with inotify to provide that kind of support to it?
http://marc.theaimsgroup.com/?l=linux-kernel&m=1102
On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> This is similar to Inotify in that the audit subsystem watches for file
> system activity and collects information about inodes its interested
> in, but this is where the similarities stop. Despite the fact that the
> Inotify re
Hello,
This patch augments the audit subsystem and VFS to support file system
auditing in which an object is audited based on its location and name.
Depending on the administrator's requirement, this feature can be used
standalone or in conjunction with the (device,inode)-based filters. The
On Wed, Jul 06, 2005 at 11:54:41AM -0500, Timothy R. Chavez wrote:
> To implement this feature we rely on the concepts of a "watch" and
> "watch list". Directories hold lists of "watches" (ie: "watch lists")
> that describe auditable file names one level beneath them. If a file
> holds a pointer
28 matches
Mail list logo
