begin quoting John H. Robinson, IV as of Wed, Apr 20, 2005 at 03:48:32PM -0700: > Stewart Stremler wrote: [snip] > > Often, you can deduce those web-pages from inspections of others. A > > webcomic that has the form "http://foo.bar.baz/comic/YYYYMMDD.html"; > > and the "http://foo.bar.baz/index.html"; just redirects to that Y/M/D > > page. So you guess try looking at tomorrow's page.... whoops! > > That kind. I was thinking more like the kind where you put the file in a > directory named for the md5sum of the file itself.
Ah. I tend to think as that as more 'random' than 'obscured', even though it's technically not random. > Otherwise you are > dealing with something akin to a weak password, such as my dog's name. ""? [snip] > I've done that before, only without paying. I was able to deduce the > ``pay'' url buy the javascript code in the html itself. Oops. Exactly. > Of course, I consider that the case of putting a cheap lock on a door, > then leaving the door open. Or hanging the key on a nail right next to the lock. [snip] > I don't consider the loss(destruction) so much a security concern. That > is more of disaster prevention. When I think ``secure'' as applied to > digital data, I think prevention of unauthorised access. Safe would > imply prevention of loss. > > Safe and Secure is what we want, ideally. Yes. And it's a more precise terminology, too. [snip] > > That just smells too much like a cop-out to me. > > Of course. You are seeing what we see to be a mirage, and claiming it to > be real. Hard to argue with that. The only real answer is to allow you, > or whomever, to believe what you want. Not so much as a mirage, but as a saddle-point right near the edge of the data. > I, personally, will argue only to > a point then I will be done with it. As I said earlier, teaching cows to > sing (it wastes your time, and annoys the cow). I'm very near the point of just being done with it. > Speaking of the mythical single user Linspire (since this is the topic > at hand, not the pre OSX MacOS systems), there is no such thing I Granted. I was just searching for a long-running example. > contend (I need to run an experiment, of course, to test my hypothesis). > To the users behind them, they are real single user systems. They > believe the mirage. We need to show them that it is a mirage. > > How to do that, though. I'm at a loss for, at the moment. I am only > being able to deduce the problem spec as we continue to explore. Now that we've bashed out most of the math, time to take some measurements? [snip] > > Nope. You're presuming that people do what's best for themselves. This > > is often not the case. It really drives game-theorists batty. > > Cost/Benefit. Sometimes, doing the good thing (eating vegetables) costs > too much (icky taste). Other times, we require the influence of an > external force (the State) to ensure we do the right thing (keep our > motor vehicles insured). Yup. > > > 2) On a single user system, a user compromise is effectively the same as > > > a root(admin) compromise. > > > > > > If this is true, a single user system must exist. We have seen that > > > these are actually rare. > > > > No, we have not. Single-user LINUX systems may be rare, yes. But we > > have NOT seen that single-user _systems_ are rare. > > Linspire, the topic we are talking about, is a LINUX system. Point > stands. Accepted. But then 'rarity' has no point. Either they exist, or they don't. > If we wish to talk about Mac OS up to and including 9, then we may have > something to talk about. Of course, I will be at quite the disadvantage, > as the only thing I know about them is that the US Army pointed out they > run no services by default. That, and I hate their interface. The latter > just means I have no experience with them. If we get into generalities, which is where we seemed to be headed, we should include systems like that. And if they differ greatly from what we see with Linspire, we need to ask why. [snip] > > It goes back to premise 1, yes, but I don't accept that premise 1 is > > flawed. > > I will concede that on a given single user box, well, any box really, > the important thing is the data. This is analogous to a building or a > safe. The infrastructure is there to protect the contents (be it people, > or documents), not for its own sake. Otherwise it would be merely art, > and while that is a worthwhile goal, it is not the practical one we talk > about. Yes. > Some people value data higher than others. If we talk about people that > don't care, those that would run as root, then all we can hope is that > one day they do care. Er, sorta. People value data differently, yes. Those who don't care might want to AVOID running as root, as a compromise doesn't affect the stability, and they can routinely trash /home (reimage it?) without concern. Boundary conditions are always tricky. > Those that do care, well, they will listen. Because they care. These are > the people that do eat their (icky!) vegetables and would keep auto > insurance coverage on their vehicles, even without law mandating it. Yup. Because good habits generally pay off in the long run. > I am starting to think we are talking about the wrong people. I am > seeing three classes right now: > Hopeless: those that don't care > Clueless: those that care, but don't know how > Flawless: those that care, and know how to do the right thing. Hmmm.... > The Hopeless cases will basically stay there until they care, and move > into clueless (or flawless, depends upon how much they are instructed > in that state). The clueless are like the newbies. They want to do the > right thing, they just don't know what it is. We spend a lot of time > with them. In some ways, all of us are in this category. The flawless > (well, bit of a misnomer there, really) have already learned. I don't really like putting 'clueless' in the 'care' bin. Clueless don't know that they should care. And we need a step between Clueless and Flawless. Those who care, and try, even if it's not always enough, or the right thing. > You are free to modify my labels. Sure, just as soon as I can think of some better ones. :) [snip] > > Kicking a dead body is insulting, but it doesn't matter to the body. > > It's still dead. > > True. Not sure what dead body we are talking about, though. Part of > the UNIX security model is protecting from oneself. Losing your data gives you the dead body. Trashing the OS after that just kicks it. [snip] > > > I am not making an artificial distinction between things like .doc files > > > or .jpegs, and the rc/.ini files. > > > > What are some highly-configured applications? > > > > I think this is one of the stronger examples, if we work on it a bit. > > I'm sure. I am just pointing the way. Network configurations. Nameservers. PPP was already mentioned. The sources.list for apt, presumably. . . [snip] > > If we're going to trot out best practices, we ought to trot out the > > whole kit and caboodle. Which is fine, but that makes _most_ systems > > guilty of failing to live up to best practices. I'm happy with that! > > Me too. Best practice is to deny root logins period. I know of very few > sites that do that. Everything with sudo? Do they disallow su as well? [snip] > > > Some people do not learn from other people's mistakes. I won't argue > > > with them. You are filling the role of that person. To them, I will give > > > > Oh, chill already. > > I mean that you are playing devil's advocate. I caught onto that early > on ;) Ah, I should have guessed. Apologies for miscontrueing your point. [snip] > > No, not me. I'm just objecting to sloppy reasoning and wishful thinking. > > Generic you, not specific you (damn the english language!) Do we need to start writing 'gyou'? [snip] > > That important data is not destroyed, corrupted, compromised; that > > resources are not damaged, made unavailable, or accessed by unauthorized > > users. (From memory.) > > Sounds like a blend of safe (prevent damage) and secure (prevent > unauthorised access). I tend to think of it in terms of data and resources, versus damage and access. Works either way, I suppose. :) [snip] > There is the hypothetical, then there is the practical. Hypothetically > speaking, we can presume any number of impossible conditions. In the > practical, we have to reduce that to a bare minimum, ideally zero. True. > In this Linspire discussion, we are trying to be practical. I assume so, > anyway. This is why we try to remain a focused (limit our discussions to > the real Linux distro called Linspire, and using UNIX type constructs) > > So far, the only thing I have seen useful in this discussion is to > better define the problem spec. Others may see things differently. Isn't it so nailed down by now that it's toes are rusting? > > It's important in these sorts of debates to play fair > > I agree. It's also one of the hardest things to do. :) -Stewart "Can I hand over the reigns to someone now?" Stremler
pgpP1Ii7Ab5Km.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
