Stephen Smalley <[EMAIL PROTECTED]> writes:
> Possibly, during setup upon initial policy load (initiated by /sbin/init
> these days) from selinux_complete_init, as early userspace may have
> already been accessing them.
I believe if we chose we could walk the dentry tree under the root inode
and
On Thu, 2007-02-08 at 10:53 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> >
> > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't
> > truly private to the fs, so we can run into them in a variety of
> > security hooks beyond just the inode
Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't
> truly private to the fs, so we can run into them in a variety of
> security hooks beyond just the inode hooks, such as
> security_file_permission (when reading and writing them
On Wed, 2007-02-07 at 15:21 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> > Actually, on further inspection, it looks like the real issue is the
> > "path" name generation; "cat /proc/sys/kernel/modprobe" yields a call to
> > security_genfs_sid() with just "/mod
On Wed, 2007-02-07 at 18:57 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> >
> > One related but separate issue is that the /proc/sys inode labeling is
> > also affected by the sysctl patch series. Those inodes used to be
> > labeled by selinux_proc_get_sid (fro
Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> One related but separate issue is that the /proc/sys inode labeling is
> also affected by the sysctl patch series. Those inodes used to be
> labeled by selinux_proc_get_sid (from selinux_d_instantiate), but that
> no longer works, so they now fall b
Stephen Smalley <[EMAIL PROTECTED]> writes:
> Actually, on further inspection, it looks like the real issue is the
> "path" name generation; "cat /proc/sys/kernel/modprobe" yields a call to
> security_genfs_sid() with just "/modprobe" rather than the expected
> "/sys/kernel/modprobe". Which likew
On Wed, 2007-02-07 at 16:12 -0500, Stephen Smalley wrote:
> On Wed, 2007-02-07 at 13:24 -0500, Stephen Smalley wrote:
> > On Tue, 2007-02-06 at 14:21 -0700, Eric W. Biederman wrote:
> > > This time instead of generating the generating the paths from
> > > proc_dir_entries
> > > generate the labels
On Wed, 2007-02-07 at 13:24 -0500, Stephen Smalley wrote:
> On Tue, 2007-02-06 at 14:21 -0700, Eric W. Biederman wrote:
> > This time instead of generating the generating the paths from
> > proc_dir_entries
> > generate the labels from the names in the sysctl ctl_tables themselves.
> > This
> >
On Tue, 2007-02-06 at 14:21 -0700, Eric W. Biederman wrote:
> This time instead of generating the generating the paths from proc_dir_entries
> generate the labels from the names in the sysctl ctl_tables themselves. This
> removes an unnecessary layer of indirection, allows this to work even when
>
This time instead of generating the generating the paths from proc_dir_entries
generate the labels from the names in the sysctl ctl_tables themselves. This
removes an unnecessary layer of indirection, allows this to work even when
procfs support is not compiled into the kernel, and especially all
11 matches
Mail list logo