From: Alan Cox on
> > SELinux users would not need the other LSM, and stacking is thus not
> > required.
>
> But if a user wants to disable ptrace using the SELinux LSM and then
> also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.

Thats a nonsensical configuration so we don't care. If you are using
SELinux you just do it via SELinux. If you are doing it via
UbuntuHasToBeDifferent then you do it via that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Randy Dunlap on
On Thu, 17 Jun 2010 21:53:49 +0100 Alan Cox wrote:

> > > SELinux users would not need the other LSM, and stacking is thus not
> > > required.
> >
> > But if a user wants to disable ptrace using the SELinux LSM and then
> > also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.
>
> Thats a nonsensical configuration so we don't care. If you are using
> SELinux you just do it via SELinux. If you are doing it via
> UbuntuHasToBeDifferent then you do it via that.


Well, surely there are people who use something other than Ubuntu
and also care about not using SELinux... eh?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kees Cook on
On Thu, Jun 17, 2010 at 02:06:30PM -0700, Randy Dunlap wrote:
> On Thu, 17 Jun 2010 21:53:49 +0100 Alan Cox wrote:
>
> > > > SELinux users would not need the other LSM, and stacking is thus not
> > > > required.
> > >
> > > But if a user wants to disable ptrace using the SELinux LSM and then
> > > also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.
> >
> > Thats a nonsensical configuration so we don't care. If you are using
> > SELinux you just do it via SELinux. If you are doing it via
> > UbuntuHasToBeDifferent then you do it via that.
>
>
> Well, surely there are people who use something other than Ubuntu
> and also care about not using SELinux... eh?

And for them, it certainly seems like a good idea to be able to turn off
PTRACE without having to fiddle with an LSM.

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kees Cook on
On Thu, Jun 17, 2010 at 01:45:02PM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook(a)canonical.com> writes:
> > On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> >> Kees Cook <kees.cook(a)canonical.com> writes:
> >> > running state of any of their processes. For example, if one application
> >> > (e.g. Pidgin) was compromised, it would be possible for an attacker to
> >> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
> >> > etc) to extract additional credentials and continue to expand the scope
> >> > of their attack without resorting to user-assisted phishing.
> >>
> >> This is ineffective. As an attacker after I gain access to a users
> >> system on ubuntu I can wait around until a package gets an update,
> >> and then run sudo and gain the power to do whatever I want.
> >
> > I doesn't stop phishing, correct. But it does stop immediate expansion of
> > an attack using already-existing credentials.
>
> sudo last I checked caches your password for a couple of seconds.
> So if you can probe the system to see when those couple of seconds
> are.

Sure, that's a downside of sudo, which is why privilege elevation has been
tending to move towards PolicyKit, FWIW.

> The archives of the containers list.
> https://lists.linux-foundation.org/pipermail/containers/ or just
> looking.

I'll go dig around.

> Things like /proc/sys/ will be default stay in the same user_namespace
> and root in other user namespaces will only get world permissions when
> accessing files.

Excellent. I'll move my questions about this to the containers mailing
list.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> > Thats a nonsensical configuration so we don't care. If you are using
> > SELinux you just do it via SELinux. If you are doing it via
> > UbuntuHasToBeDifferent then you do it via that.
>
>
> Well, surely there are people who use something other than Ubuntu
> and also care about not using SELinux... eh?

Then they can load UbuntuSecurity and use that, just enabling the
features they want.

I'm not against the Ubuntu stuff getting beaten into a security module
and put where it belongs. Far from it - I just want to see it put where
it belongs, which is not junk randomly spewed over the tree. Doubly so
when they do it wrong *because* they are not using the security hooks.

It seems pretty easy to me. Kees needs to package up the grsecurity
features that Ubuntu thinks are valuable into security/something/... with
a set of sysfs entries to turn on/off the various features. Ubuntu is
happy, people who want a simple set of sysfs feature controls for
security are happy and nobody else will even notice.

It'll appeal to some people because it looks easy to work and it won't
upset anyone else because its all nicely filed away where it belongs.

We don't put MSDOS fs hacks randomly all over the VFS[1], please don't try
and put security hacks into random bits of kernel code.

Alan
[1] Maybe we should be scarier, like Al ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/