Stewart Stremler wrote: > begin quoting John H. Robinson, IV as of Wed, Apr 20, 2005 at 12:18:15PM > -0700: > > Stewart Stremler wrote: > [snip] > > > No, it isn't. It's a secret. > [snip] > > > Erm, that's not the example that comes to mind for me. I'm thinking of > > > code obfuscation, unpublished encryption algorithms, and created web-pages > > > that have no public links to them. > > > > What is the difference between a password that no one knows (a secret) > > and an url that has no links to it (obscure). > > Well, no _public_ links. > > > Either way, only those that know have it. It cannot be found by any > > other means short of brute forcing. Not all password schemes can support > > limitless passphrases, but I have seen nastily long urls that would put > > most passphrases to shame. I am yet to find a wedserver that will not > > support 1024+ long urls. > > 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. Otherwise you are dealing with something akin to a weak password, such as my dog's name. > Then you see that the artist will let you look at low-res images for > ree, and download high-res images if you pay for 'em. You pay for one > or two, and notice that the high-res image is the basename of the > low-res image rot13'd -- obfuscated, but deducable. 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. Of course, I consider that the case of putting a cheap lock on a door, then leaving the door open. > > So, where is the practical difference between an unknown token > > (password) and an unknown token (url)? > > Progressions. > > And, presumably, sniffing the wire to look for those long urls being > sent in the clear. > > When we start encrypting very-long randomized urls, we're dealing with > secrets. https! > > > Keeping just one copy of your data strikes me as a security concern. > > > > Keeping multiple copies seems an even greater security concern. > > Conflicting security concerns. Are you worried about loss, or > unauthorized distribution? 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. > With just one copy, you have to worry about corruption. (So you keep > a history of crcs and md5 hashes?) > > Sometimes, there aren't any simple solutions. :) If you are backing up your data . . . > [snip] > > > WE don't run as root because WE run servers and multi-user machines. > > > > I thought we had established (though not to your satisfaction) that the > > single-user computer is a nonesuch. > > "I cannot refute your assertion, so I declare it meaningless!" No, the argument is not meaningless. It is misplaced. > > If it works for you, great. > > 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. 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). 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 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. > > > You've already lost your data in this case. Why are you worrying about > > > the OS? > > > > We are working from flawed premises: > > > > 1) (User) Data is King > > I don't think this is flawed. > > > If this is true, then data would be protected. Single user people rarely > > (this is well documented) back up (read: protect) their data. Data is > > not king. Premise one defeated. > > 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). > > 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. 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. > > 3) A user can damage their own data as well as root can. > > > > This goes back to premise 1, which is flawed. > > 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. 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. 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. 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. 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. You are free to modify my labels. > > We can stop discussing > > here. However, I contend that root has a larger class of powers that > > enable him to destroy a user's data than a user does. This allows for > > more problems. > > 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. > > > Example: toasting the application. Since a mere user cannot do that, but > > root can, this requires the application to be re-installed. Sometimes, > > this destroys user data too. Sometimes that data is in the form of > > configuration files. > > > > 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. > (For example, ppp configurations. A PITA to set up.) > > (So that's one-and-an-eighth good reasons...) Heh. > > Best practice dictates that admin functions be performed by an admin > > role, and non-admin stuff be performed by non-admin. > > Best practices dictate that we have multiple partitions; that we > actually enforce least privilege; that we have a system for guaranteeing > an actual system login prompt; that we do not let uninspected scripts > run with administrative privileges... > > 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. > > Because we like car anologies :) (We all do, don't deny it). We wear > > normal clothes when driving the car, but wear our grease stained clothes > > when working on it. We are the same person, but different roles. > > Um, I know lots of people that wear the same clothes whether they were > working on their car or driving it. (More in my youth; these days, most > folks don't seem to work on their own cars too much, myself included.) > > [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 ;) > > them all the rope they want, let them fashion their neat and interesting > > nooses, and hang themselves in the noonday sun. When they come back, and > > are willing to learn, then we go over everything we have discussed. > > Did you not catch the bit at the beginning of the thread where I talked > about bad habits? Nah, I saw that. > > Then they are ready for the teachings of the ancients (to mix metaphors > > badly). Before then, you are merely teaching a cow to sing. > > No, not me. I'm just objecting to sloppy reasoning and wishful thinking. Generic you, not specific you (damn the english language!) > > > No... I'm saying that difficulty for its own sake does not make things > > > any better. I demand that additional difficulty in the name of security > > > ought to actually provide a concomitant improvement in security. > > > > We throw this word around - security. What are we actually saying? What > > do we actually mean? > > 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 contend that the whole argument is flawed, because it presumes > > conditions that do not and cannot exist. > > Then you've just self-selected yourself out of the discussion. Atheists > don't get to discuss the fine points of theology when they counter every > argument that goes against them with 'well, there is no god anyway'. 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. 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. > It's important in these sorts of debates to play fair I agree. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
