Upstream first policy
in [Kernel]
|
Prev: fork problem in multithreaded process -- segmentation fault seen
Next: [PATCH 2/2 V3] io-controller: Document for blkio.weight_device
From: Ulrich Drepper on 9 Mar 2010 10:00 On Tue, Mar 9, 2010 at 00:46, Dave Airlie <airlied(a)gmail.com> wrote: > selinux relabels are the new fsck. > > maybe we need selinux3 or chunk-selinux. Once the fanotify stuff is in (or however it'll be called) the new relabel process could temporarily install itself to intercept all filesystem operations and fix up files on demand while going along it's normal operation in the background. No reason to stall the system completely. If this is the biggest complaint then you should be supportive of the approach. -- 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: Florian Mickler on 9 Mar 2010 12:20 On Mon, 8 Mar 2010 18:18:21 -0500 Eric Paris <eparis(a)parisplace.org> wrote: > You do realize that with content based security systems the pathnames > aren't important and you could implement your example patch? Sure a > user could mount something on /lib and put their own files there, but > since that user couldn't get them labelled correctly the suid app > would not be able to use them and would fail. Users would have new > and interesting way to break their computers! but isn't that why a pathname based protect of /lib would be better? so that users couldn't break their system? >I thank you for your > vote for content based security systems instead of pathname systems > and look forward to your future contributions to either that body of > knowledge or the bridging of the gap between the two *smile* > > -Eric i interpret it not this way. but i'm an amateur securita :) cheers, Flo -- 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 9 Mar 2010 18:10 > time. If pathnames were not fundamentally important we could apply > a patch like the one below and allow unprivileged users to unshare > the mount namespace and mount filesystems wherever. There is nothing > fundamental about those operations that require root privileges except > that you are manipulating the pathnames of objects. And in a purely SELinux enviromnment your patch would work out because you could use labels to control this stuff. > - if (!capable(CAP_SYS_ADMIN)) > - return -EPERM; > - It does raise the question about whether you can do it if you had a namespace property of "ignore suidness". I'm not sure thats enough however. -- 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: Eric W. Biederman on 10 Mar 2010 23:00 Weird. Somehow I only got a copy of this from lkml. Alan Cox <alan(a)lxorguk.ukuu.org.uk> writes: >> time. If pathnames were not fundamentally important we could apply >> a patch like the one below and allow unprivileged users to unshare >> the mount namespace and mount filesystems wherever. There is nothing >> fundamental about those operations that require root privileges except >> that you are manipulating the pathnames of objects. > > And in a purely SELinux enviromnment your patch would work out because > you could use labels to control this stuff. > > >> - if (!capable(CAP_SYS_ADMIN)) >> - return -EPERM; >> - > > It does raise the question about whether you can do it if you had a > namespace property of "ignore suidness". I'm not sure thats enough > however. The long term plan is to change that to. if (nscapable(mnt_ns->user_ns, CAP_SYS_ADMIN)) return -EPERM. That is. - Create a new user/credential namespace (ultimately an unprivileged operation). - Have the root user of the new user namespace create a new mount namespace. - Over that new mount namespace the root user of the new user namespace has full control. It is a little convoluted but it maintains backwards compatibility. Unfortunately there is still a long ways to go before we get there. Eric -- 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: Pavel Machek on 23 Mar 2010 10:10
Hi! > > Also, why was/(is?) AppArmor considered as a 'hostile competitor' > > I don't believe it was. It was perceived as a technical failure, and then > the file system people shredded the bits the security folks didn't. Unfortunately, in the meantime tomoyo was merged, which is basically apparmor done wrong. So I guess I owe an apology to apparmor people :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/ |