Eric Paris redhat.com> writes:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > >
> > > I wonder if the default should be for this value to be zero (i.e.
> > > preserve
> > >
Eric Paris eparis at redhat.com writes:
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e.
preserve
existing
Hi!
> > While I understand, there are a few users who will have problems with
> > this default are we really better to not provide this defense in depth
> > for the majority of users and let those with problems turn it off rather
> > than provide no defense by default? I could even provide a
Hi!
While I understand, there are a few users who will have problems with
this default are we really better to not provide this defense in depth
for the majority of users and let those with problems turn it off rather
than provide no defense by default? I could even provide a different
On Jun 6 2007 08:47, Stephen Smalley wrote:
>
>I'd be ok with having a different default for SELinux vs. non-SELinux,
>i.e. no restrictions by default under dummy/capability, but restrict it
>by default to 64k if selinux is enabled. Then we can use policy to
>grant it as needed to the specific
On Jun 6 2007 08:47, Stephen Smalley wrote:
I'd be ok with having a different default for SELinux vs. non-SELinux,
i.e. no restrictions by default under dummy/capability, but restrict it
by default to 64k if selinux is enabled. Then we can use policy to
grant it as needed to the specific
* Eric Paris ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > >
> > > I wonder if the default should be for this value to be zero (i.e.
> > > preserve
> >
On Wed, 6 Jun 2007, Stephen Smalley wrote:
> With the fix already noted by James,
>
> Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
Final patch applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm
Also queued there is the following patch which enables
On Wed, 2007-06-06 at 02:30 -0400, Eric Paris wrote:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > >
> > > I wonder if the default should be for this value to be zero (i.e.
> > >
On Wed, 6 Jun 2007, Eric Paris wrote:
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "mmap_min_addr",
> + .data = _min_addr,
> + .maxlen = sizeof(unsigned long),
> + .mode = 0644,
> +
On Tue, 2007-06-05 at 17:28 -0400, Eric Paris wrote:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > >
> > > I wonder if the default should be for this value to be zero (i.e.
> > >
On Wed, 2007-06-06 at 19:01 +1000, Russell Coker wrote:
> On Wednesday 06 June 2007 06:34, Eric Paris <[EMAIL PROTECTED]> wrote:
> > This patch uses a new SELinux security class "memprotect." Policy
> > already contains a number of allow rules like a_t self:process *
> > (unconfined_t being one
On Tue, 2007-06-05 at 15:53 -0700, Chris Wright wrote:
> * Eric Paris ([EMAIL PROTECTED]) wrote:
> > One result of using the dummy hook for non-selinux kernels means that I
> > can't leave the generic module stacking code in the SELinux check. If
> > the secondary ops are called they will always
On Wednesday 06 June 2007 06:34, Eric Paris <[EMAIL PROTECTED]> wrote:
> This patch uses a new SELinux security class "memprotect." Policy
> already contains a number of allow rules like a_t self:process *
> (unconfined_t being one of them) which mean that putting this check in
> the process
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > This should be an unsigned long.
> >
> > I wonder if the default should be for this value to be zero (i.e. preserve
> > existing behavior). It could break binaries, albeit
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially
On Wednesday 06 June 2007 06:34, Eric Paris [EMAIL PROTECTED] wrote:
This patch uses a new SELinux security class memprotect. Policy
already contains a number of allow rules like a_t self:process *
(unconfined_t being one of them) which mean that putting this check in
the process class (its
On Tue, 2007-06-05 at 15:53 -0700, Chris Wright wrote:
* Eric Paris ([EMAIL PROTECTED]) wrote:
One result of using the dummy hook for non-selinux kernels means that I
can't leave the generic module stacking code in the SELinux check. If
the secondary ops are called they will always deny
On Wed, 2007-06-06 at 19:01 +1000, Russell Coker wrote:
On Wednesday 06 June 2007 06:34, Eric Paris [EMAIL PROTECTED] wrote:
This patch uses a new SELinux security class memprotect. Policy
already contains a number of allow rules like a_t self:process *
(unconfined_t being one of them)
On Tue, 2007-06-05 at 17:28 -0400, Eric Paris wrote:
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e.
preserve
On Wed, 6 Jun 2007, Eric Paris wrote:
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = mmap_min_addr,
+ .data = mmap_min_addr,
+ .maxlen = sizeof(unsigned long),
+ .mode = 0644,
+
On Wed, 2007-06-06 at 02:30 -0400, Eric Paris wrote:
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e.
preserve
On Wed, 6 Jun 2007, Stephen Smalley wrote:
With the fix already noted by James,
Acked-by: Stephen Smalley [EMAIL PROTECTED]
Final patch applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm
Also queued there is the following patch which enables the
* Eric Paris ([EMAIL PROTECTED]) wrote:
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e.
preserve
existing
* Eric Paris ([EMAIL PROTECTED]) wrote:
> One result of using the dummy hook for non-selinux kernels means that I
> can't leave the generic module stacking code in the SELinux check. If
> the secondary ops are called they will always deny the operation just
> like in non-selinux systems even if
* Eric Paris ([EMAIL PROTECTED]) wrote:
> +mmap_protect_memory
I'm terrible at names, but something like mmap_minimum_addr would be a
little clearer at describing that it's a lower bound on mapping memory.
BTW, this is also an arch specific issue, those with disjoint kernel
and user memory space
Eric Paris wrote:
>
> While I understand, there are a few users who will have problems with
> this default are we really better to not provide this defense in depth
> for the majority of users and let those with problems turn it off rather
> than provide no defense by default? I could even
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > This should be an unsigned long.
> >
> > I wonder if the default should be for this value to be zero (i.e. preserve
> > existing behavior). It could break binaries, albeit
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> This should be an unsigned long.
>
> I wonder if the default should be for this value to be zero (i.e. preserve
> existing behavior). It could break binaries, albeit potentially insecure
Agreed - DOSemu type apps and lrmi need to
On Tue, 5 Jun 2007, Eric Paris wrote:
> +extern int mmap_protect_memory;
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially insecure
ones.
- James
--
James Morris
Assuming there is a kernel bug which includes a null dereference that
bug may allow for a process to place information on the first page on
the system and get the kernel to act in unintended ways. This patch
adds a new security check on mmap operations to see if the user is
attempting to mmap to
Assuming there is a kernel bug which includes a null dereference that
bug may allow for a process to place information on the first page on
the system and get the kernel to act in unintended ways. This patch
adds a new security check on mmap operations to see if the user is
attempting to mmap to
On Tue, 5 Jun 2007, Eric Paris wrote:
+extern int mmap_protect_memory;
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially insecure
ones.
- James
--
James Morris
[EMAIL
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially insecure
Agreed - DOSemu type apps and lrmi need to map
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially
* Eric Paris ([EMAIL PROTECTED]) wrote:
One result of using the dummy hook for non-selinux kernels means that I
can't leave the generic module stacking code in the SELinux check. If
the secondary ops are called they will always deny the operation just
like in non-selinux systems even if
* Eric Paris ([EMAIL PROTECTED]) wrote:
+mmap_protect_memory
I'm terrible at names, but something like mmap_minimum_addr would be a
little clearer at describing that it's a lower bound on mapping memory.
BTW, this is also an arch specific issue, those with disjoint kernel
and user memory space
Eric Paris wrote:
While I understand, there are a few users who will have problems with
this default are we really better to not provide this defense in depth
for the majority of users and let those with problems turn it off rather
than provide no defense by default? I could even provide a
38 matches
Mail list logo
