First, I can't really understand why either one of you two won't fully explain your reasonings when going against the other. It helps noone.
On 2006-02-17 19:04, Hemmann, Volker Armin uttered these thoughts: > On Friday 17 February 2006 07:33, Alexander Skwar wrote: > > Hemmann, Volker Armin wrote: > > > On Thursday 16 February 2006 20:40, Alexander Skwar wrote: > > >> Hemmann, Volker Armin wrote: > > >> > On Thursday 16 February 2006 17:18, Alexander Skwar wrote: > > >> >> Hemmann, Volker Armin wrote: > > >> >> > > > >> >> > Why should he make /tmp noexec, > > >> >> > > >> >> Security precaution. > > >> > > > >> > if you have 10+ users with access to the box. But a workstation, > > >> > without even sshd running, it is not needed. Of course, if you have a system with _no_ services running (including apache, sshd and so on), or a firewall that blocks every and all incoming connection attempt, then for someone to access /tmp without having physical access to the system (in which case you're pretty much screwed anyhow) is, as far as I know, impossible. This doesn't take into account client-side exploits; because with these the exploiting code has access to whatever resources the user running the client has, including writing to whatever areas that the user has. > > >> "needed" - What's "needed", anyway? > > >> > > >> > And hey, why should /tmp noexec save you from anything? > > >> > > >> Because it does. > > > > > > so? how? > > > > Think, you might find out. What does noexec do, hm? > > > > Even *you* might find out... > > > > Well... If I think about it... No, you're too clueless > > to find out. > > > > Hint 1: "noexec" nowadays makes it impossible to execute > > programs stored on that filesystem. > > I know, but it won't save you from anything. > After a user got in, he is a user. And every user has a place with write > permission (if he is user apache/httpd he has lots of places, where he can > store code). Outside of /tmp. Where? If you've locked down your system tight enough (with file permissions, noexec and so on), I'd guess that the places where things can be stored _and_ be executed from is pretty limited. > You see - it doesn't help you anything. I disagre, but if you're under that impression you're not forced to go that route... But I'd advice you from expressing this opinion to people not knowing better. > > Hint 2: /tmp (and /var/tmp) are (hopefully) the only places > > where everybody can write. > > an attacker does not need a place, where everybody can write. He just needs > SOME place, where he can write - like the home-directory of the user he just > corrumpted. What's to say that the only way to get access to a system is through hacking a user account? Exploits have existed (and probably does, if not in older code) that uses /tmp, and the ability to execute things from that location, to get access to more privileges. So having /tmp mounted as noexec is a good security measure from these kind of exploits. > Also, he can disrupt your system, by just filling up /tmp. No code needed for > that. And that is the exact reason for keeping "writable by all" locations on separate filesystems, so that the damage can be limited and not make the entire system unusable if someone decides to fill up a filesystem. > > >> > If someone is able to break into your box, he can build his tools in > > >> > /home or /var/tmp or somewhere else. No need for /tmp. > > >> > > >> Wrong again. If tmp is the only place somebody can write, then > > >> it might save you (and it DID save my ass more than once now). > > > > > > since /tmp is not the only place where someone can write (/var/tmp > > > anyone?) > > > > True. /var/tmp is a link to /tmp on my system. And if not, /var/tmp > > could also easily be a seperate fs. > and another partition ..,. Not necessarily a partition (by using LVM), but ok. I really don't get why this is a problem if you can easily extend the size of these filesystems, which it is when using LVM or an eqvivalent system. > > > it > > > won't help you much. > > > > That's of course wrong again. > > > > >> >> Ah. Please explain how you mount /tmp noexec and /usr > > >> >> readonly. > > >> > > > >> > I don't because it is wasted effort. > > >> > > >> Of course it's not. > > > > > > yes it is. > > > > Jaja. Just because you've got problems, it doesn't mean > > that there ARE problems. > > it is wasted: if he has so many rights, that he could write to /usr, he has > enough rights to remount it. > and /tmp is not needed, as soon as you have breaken into the box. > Plus, a full /tmp and /var will disrupt services and make reboot (almost) > impossible. > > So, noexec and ro /usr will save you from nothing. > > > No, it's not. Write permissions don't mean, that somebody is root. > > in my /usr, yes it does. > ;) That's I think your problem with this entire approach. You only see your specific scenario. It's fully possible to have write privileges to /usr without having to be root. > > > yes really, you have to remount /usr everytime you update something. > > > > Jaja. You know, your exaggerations become boring... > > because it is true? > show me, how do you update something residing in /usr without remounting. You don't. But saying that remounting /usr when you do updates takes up an unreasonable amount of time is pretty much moot if you take a couple of minutes to script your update procedure. > > a) /tmp is cleaned during boot - so this won't happen anyway. > > /tmp ios cleaned so late, that it is too late, is both are totally full. > > > b) Don't let it happen in the first place. > you can not tell an attacker what not to do. > > > c) Boot a rescue system like Knoppix and clean /tmp. > > yeah! but why boot from a boot-cd, if you don't have to? (hint: /tmp not on > its own, small partition) Oh yeah, it's much better to have /tmp on the same filesystem as /, making the system unusable as soon as you fill up /tmp. Good suggestion ;) > > d) In reality, I NEVER had it happen that /tmp or /var/tmp > > ran out of space. What happened "more often" is that /var > > ran out of space, because of the logs in /var/log. > > you have never used gimp, did you? > I have seen gimp filling up a 5GB /tmp. > > > > > >> >> I see. Strange thing is, that about every server and workstation > > >> >> I've seen more or less contradicts what you say. > > >> > > > >> > if you have 20+ users on each of them, and every single one is a > > >> > little cracker in disguisse, it may make sense, but for a single user > > >> > box? > > >> > > >> Why are you asking? > > > > > > because you are the one starting with 'server' and 'workstations' > > > > Correct. So what? Why are you asking? > > > > > and the OP > > > never talked about one or the other. > > > > His system MUST be the one or the other. > > nope, there is a third category: personal computer (also called home > computer). What's this got to do with anything at all? > > >> > If every partition takes a second, it will be very noticable. > > >> > > >> Hardly. (Notice that I'm not saying "No".) > > > > > > if mounting becomes the major 'hold up' in your booting process, it > > > becomes VERY noticable. > > > > Jaja. Do you actually expect to be taken seriously? > > not from you. From thois mailing list I learnt, that if someone is not on > your > side, the person is wrong. Good philosophy. Good luck getting through life with that attitude. > > > I have been there, > > > > I doubt that. > > Why should I lie? > I had 3 ibm harddisks 1x10Gb,2x40gb one seagate 20gb and all and everything > on > its own partition. > And it was hell after a while. I would imagine it could get pretty screwed up using ordinary partitions which you can't resize easily. But from Alexander's point of view this is pretty much moot since it seems that extending filesystems using LVM is extremely easy and fast. > > > More harddisks=bigger chance that one of them dies. So, instead of spreading your data out over several harddrives (reducing the chance of loosing _all_ your data when a harddrive dies), you'd rather have everything on one harddrive, thus loosing all your data when that harddrive dies... Best suggestion I've heard in a long time ;) > > True. So? What does this have to do with the fact, that the > > available hd's are too small? Just as a reminder - that's > > the scenario YOU are talking about. > > becuase you started with 'buy more harddisks' > > > >> > It is simple math. > > >> > > >> *LOL* _You_ should not talk about maths :) > > > > > > you obviously don't understand simple statistics. The statistics in your reasoning really has no bearing in the argument, since harddrives will fail no matter how many (or few) harddrives you have. And even though having more harddrives increases the chance of one of them failing, how does that impact your choice in what partitioning-scheme you want to use (especially if you use LVM)? > > Seems like. But maybe it's just, that I've got problems > > following your nonsense, hm? > > you mean your nonesense? > Yep, it is hard to deal with you. > > I snipped the rest: TL:DR Wow, intelligent rebuttals here... Impressive. At the end of the day, it's basically a choice of how secure/robust you want your filesystem layout to be compared to how much tinkering you want to do to keep everything rolling along nicely. Using alot of ordinary partitions seems to be pretty outdated when we have access to LVM, and can bring alot of hassle if you have made your partitions to small, or waste alot of space if made to big. Using one partition for basically everything under / is a bit less secure if you're running a couple of services on your system, but if you're just using the system as a workstation, I wouldn't be too worried about it. Using LVM seems to be a lot more flexible since you can start small with your filesystems, and extend them after time when need be. But this also includes some supervision of how much space you have available on your different filesystems. Could probably be considered a more convenient alternative if you plan to extend your system later on with more harddrives, or plan on separating your data areas to further security/robustness. Please end the flamefest now, k? -- / Patrick Börjesson \ ------------------- / () The ASCII Ribbon Campaign - against HTML Email \ /\ and proprietary formats.
pgpFPrfUVCSC8.pgp
Description: PGP signature
