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
> > > existin
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 diff
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 pr
* 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 th
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.
> > > pr
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 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.
> > > pr
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 o
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 d
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 clas
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 poten
* 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 SE
* 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 d
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 provid
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 poten
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
<[EMAI
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 l
19 matches
Mail list logo
