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: Linus Torvalds on 8 Mar 2010 21:20 On Tue, 9 Mar 2010, Al Viro wrote: > > Doesn't have to be a binding over /etc/passwd, BTW. /etc as a mountpoint will > serve just as well. I agree. But I think more people are aware of a regular directory mount than about the ability to just mount a single file. So from a sneakyness standpoint, I like the "oh, btw, I just took over just the one file I care about" rather than trying to hide the whole directory. Doesn't matter conceptually, though. Linus -- 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: Linus Torvalds on 8 Mar 2010 23:10 On Mon, 8 Mar 2010, Casey Schaufler wrote: > > Those of you who say we ought to come up with a single framework > that we can use to Do The Right Thing haven't been reading the code. > We have such a framework in the LSM. ... and people are also interested in using (and expanding) the 'notify' layer, probably because it is obviously designed for efficiently talking at a user-level program about the relevant accesses. Whether that is because they are just crazy ("malware detection") or whether it is an indication that the LSM layer and current security models are just not convenient enough, I dunno. And whether all that has anything to do with "Do The Rigth Thing" is obviously very much unclear, but the interest is clearly there. Linus -- 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: Ingo Molnar on 9 Mar 2010 02:40 * Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Mon, 8 Mar 2010, Alan Cox wrote: > > > > man restorecond > > I know. I also sometimes sit through minutes of "let's relabel the system, > because you've booted a kernel without selinux support". I've had selinux relabeling wait times of an hour or two too, on a sufficiently large filesystem. I think this hurts security far more than anything else, because it causes people to actually _turn off the whole thing_ - so we will have less and less security in the end. ( To use the obligatory fire door analogy: we should prefer a one inch thick fire door that opens and closes fully automated to a five inches thick fire door that people keep always-open with a chair. ) Ingo -- 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: Dave Airlie on 9 Mar 2010 03:50 On Tue, Mar 9, 2010 at 5:29 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > > * Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > >> On Mon, 8 Mar 2010, Alan Cox wrote: >> > >> > man restorecond >> >> I know. I also sometimes sit through minutes of "let's relabel the system, >> because you've booted a kernel without selinux support". > > I've had selinux relabeling wait times of an hour or two too, on a > sufficiently large filesystem. > > I think this hurts security far more than anything else, because it causes > people to actually _turn off the whole thing_ - so we will have less and less > security in the end. > > ( To use the obligatory fire door analogy: we should prefer a one inch thick > �fire door that opens and closes fully automated to a five inches thick fire > �door that people keep always-open with a chair. ) selinux relabels are the new fsck. maybe we need selinux3 or chunk-selinux. Dave. -- 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: Samir Bellabes on 9 Mar 2010 08:10
Linus Torvalds <torvalds(a)linux-foundation.org> writes: > On Mon, 8 Mar 2010, Casey Schaufler wrote: >> >> Those of you who say we ought to come up with a single framework >> that we can use to Do The Right Thing haven't been reading the code. >> We have such a framework in the LSM. > > .. and people are also interested in using (and expanding) the 'notify' > layer, probably because it is obviously designed for efficiently talking > at a user-level program about the relevant accesses. Whether that is > because they are just crazy ("malware detection") or whether it is an > indication that the LSM layer and current security models are just not > convenient enough, I dunno. LSM layer gives enough to push the policy manager in userspace. Even after that to a centralized server. I worked on this, regarding networking. Next move should be to include the LSM hooks regarding filesystem. [0] I have concern about the way to do this, ie should we use the LSM layer to do this, or should we put the features directly in the filesystem stack or networking stack ? At this point, it reminds me, ipchains (kernel 2.2) vs netfilter (kernel 2.4-2.6). At the beginning, with ipchains, filtering code was directly in the network stack, and it wasn't the solution. So netfilter's hooks was designed. with LSM, we have a layer, and as sure as every one will come with his own approach, I think we should keep code in stack (network, filesystem, ...) clean, and make the defering to userspace approach as a security module. Then let the user/distro decided which features he want to use. thanks, sam [0] http://lkml.org/lkml/2010/3/2/295 -- 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/ |