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
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
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
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 (from
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 /modprobe rather
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 via
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 hooks, such
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 find
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
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
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
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
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
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
removes an
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 from the
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 back to
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
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
21 matches
Mail list logo
