--- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 29, 2007 at 11:08:39AM -0800, Casey
> Schaufler wrote:
> > Alternativly you could move the SELinux specific
> > bits out of /proc/self/attr into an equivalent
> > /selinux/self/attr and avoid that /proc
> dependency.
>
> Why?
To avo
On Mon, Jan 29, 2007 at 11:08:39AM -0800, Casey Schaufler wrote:
> Alternativly you could move the SELinux specific
> bits out of /proc/self/attr into an equivalent
> /selinux/self/attr and avoid that /proc dependency.
Why? procfs is essential for any kind of fullblown linux system,
and the selin
On Tuesday 30 January 2007 05:43, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> True, but a system that disables proc is likely a system with a custom
> policy anyway,
In practice we have to extensively customise policy long before getting to the
non-proc stage of optimising for small hardware. T
On Mon, 2007-01-29 at 11:08 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > True, but a system that disables proc is likely a
> > system with a custom
> > policy anyway, and dependency on proc is fairly
> > basic to selinux these
> > days (due to reliance on /p
On Mon, 2007-01-29 at 10:55 -0700, Eric W. Biederman wrote:
> James Morris <[EMAIL PROTECTED]> writes:
>
> > On Mon, 29 Jan 2007, Stephen Smalley wrote:
> >
> >> NAK. Mapping all sysctls to a single security label prevents any kind
> >> of fine-grained security on sysctls, and current policies al
Stephen Smalley <[EMAIL PROTECTED]> writes:
>> > If the ctl_table supplied more information about the functional purpose
>> > and the security sensitivity of the sysctl, then we could leverage that
>> > information instead, as long as we can at least derive the current
>> > labelings from that in
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> True, but a system that disables proc is likely a
> system with a custom
> policy anyway, and dependency on proc is fairly
> basic to selinux these
> days (due to reliance on /proc/self/attr for process
> attribute
> manipulation in place of the ol
On Mon, 2007-01-29 at 10:43 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2007-01-28 at 12:21 -0700, Eric W. Biederman wrote:
> >> With the sysctl cleanups sysctl is not really a part of proc
> >> it just shows up there, and any path based approach wil
James Morris <[EMAIL PROTECTED]> writes:
> On Mon, 29 Jan 2007, Stephen Smalley wrote:
>
>> NAK. Mapping all sysctls to a single security label prevents any kind
>> of fine-grained security on sysctls, and current policies already make
>> use of the current distinctions to limit access to particu
Stephen Smalley <[EMAIL PROTECTED]> writes:
> On Sun, 2007-01-28 at 12:21 -0700, Eric W. Biederman wrote:
>> With the sysctl cleanups sysctl is not really a part of proc
>> it just shows up there, and any path based approach will not
>> adequately describe the data as sysctl is essentially a
>> un
On Mon, 29 Jan 2007, Stephen Smalley wrote:
> NAK. Mapping all sysctls to a single security label prevents any kind
> of fine-grained security on sysctls, and current policies already make
> use of the current distinctions to limit access to particular sets of
> sysctls to particular processes.
On Sun, 2007-01-28 at 12:21 -0700, Eric W. Biederman wrote:
> With the sysctl cleanups sysctl is not really a part of proc
> it just shows up there, and any path based approach will not
> adequately describe the data as sysctl is essentially a
> union mount underneath the covers. As designed this
12 matches
Mail list logo
