Re: suggested /etc/skel/ modifications
> suggested /etc/skel/ modifications The reason I proposed a umask of 077 is that I discovered just a few files scattered through my directories with owner:group of root:daf (I'm daf, the only user of this system). All the other files in my directories are daf:daf, and I cannot imagine any scenario resulting in files with owner:group of root:daf except for the file .cvspass which was created when I initialized cvs. (I *never* run as root since I started using sudo and I only use sudo when I need to update a system file or install a package or other software.) Then I noticed that KDE applications were creating files all over the place with world permissions of r-x since my root directory was drwxrwxr-x. That bothered me so I reset the permissions on all my directories and also on all the KDE files.
Re: suggested /etc/skel/ modifications
Quoting Moritz Grimm <[EMAIL PROTECTED]>: > >>shell server. Who says that the admin is any more trustworthy than some > >>other, regular users? > > > > They are not, but most of the time they give you confidential information > > that you must use on that box that you use for stuff other users may > > not access, like database/pop3 information. > > Huh, why would I give shell access (or even a system account) to anyone > but fellow admins on a database or mail server in the first place? From > a user perspective, I for one would rather Post-It[tm] complicated and > unmemorizeable credentials to my monitor(*) where I have at least some > idea about who might get to see them instead of putting them into my > home directory on my own server at home, let alone some server someplace > else. > I was talking about the multi user systems you mentioned in combination why I should trust the admin from it, you use passwords on them which you get from those administrators, being a password to read your mailbox from there, or being a password from a personal database or from a system you need to check. It isn't the first time I needed to use password X to log into system Y to access service A with password B. Not mentioning I needed an account on server C to be able to connect to system Y. Where server C and Y are those multi user systems you mentioned. On the other hand, I never agreed with making it the default, only for providing a method to change that behaviour without hacking the code. Which I didn't knew it could be fixed with changing the permissions of just /etc/skel once, I only read the adduser code near the permissions. If someone did agree integrating it, I would be happy to read the next/prev lines and make the patch myself. J. This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
Re: suggested /etc/skel/ modifications
[EMAIL PROTECTED] wrote: Ever heart of a multiuser system where one user shouldn't be able to acces the files of another user? Not all users are thinking about this issue and many forget to change the modes for confidential files. IMO, But keeping confidential files on "true" multiuser systems is stupid ... I disagree, How about a heavy build server for different projects? Or shared (insert word)-solutions. You cannot be to careful with your files, one day, as normal user, you will forget to chmod() that file ... Whenever you configure a box like that, you will (have to) put more thought into it in the first place. You cannot assume that a default installation of any general purpose OS, including OpenBSD, can serve each and every possible purpose right out-of-the-box. There has to be done some careful, custom configuration. The cleanliness and lack of nasty surprises in OpenBSD might make this easy (or at least easier) to implement, but the design part is always the same. It's just as with pf - the way it works, syntax etc, is easy to understand and use, but in the end it also just does what it's told to do ... and if that part is flawed, the result will be flawed as well. I have yet to find an "insane" default setting in OpenBSD. It all makes perfect sense, and it's wonderfully simple to go into any direction from these defaults. I see no reason in changing them into what's more suitable for special cases. The things you mention are/can be pretty large projects. Paranoia never really helps security -- all it can do is prevent people from thinking straight... or worse, make them alter paranoid default settings into utterly insecure ones just to get things working again - depending on whose paranoia needs to be dealt with. In my opinion, the OpenBSD folks are walking a fine line here and doing a good job at that. IMNSHO. And you cannot hide anything from the administrator. You depend on how well the admin is capable of securing the rest of the system and not have it rooted by a 3rd party(*) including the other users. Then you shouldn't use the system at all. It is not because something might be/become a flaw, that you don't have to care about the rest. Every extra layer of defence _does_ protect you from a subset of attacks, even how small that subset is, it counts. As for how far trust goes, this needs to be figured out on a case-by-case basis. You trust because something is made trustworthy - for example through transparency in what way security is enforced. But this digresses from talking about default settings, and in this regard there might've been a misunderstanding. I did not mean to not care about the rest, but you cannot expect most or all of it from a default installation. I hope my explanation above is clearer. The fine line is to have things secure but not paranoid (and thus dysfunctional for the majority of users.) I disagree with the proposed changes to /etc/skel, because I believe that what we have here is perfectly suited for most people, and easy enough to work with for those who have special needs. shell server. Who says that the admin is any more trustworthy than some other, regular users? They are not, but most of the time they give you confidential information that you must use on that box that you use for stuff other users may not access, like database/pop3 information. Huh, why would I give shell access (or even a system account) to anyone but fellow admins on a database or mail server in the first place? From a user perspective, I for one would rather Post-It[tm] complicated and unmemorizeable credentials to my monitor(*) where I have at least some idea about who might get to see them instead of putting them into my home directory on my own server at home, let alone some server someplace else. Moritz *: Just like some well-known security guy, whose name I forgot, suggested recently ... might've been a TheRegister article pointing to it.
Re: suggested /etc/skel/ modifications
Timothy Donahue <[EMAIL PROTECTED]> wrote: > This is fairly easy to customize since the adduser command is just a > perl script. (Hint: I believe that line 1143 in 3.7 might be a good > place to start looking.) I know, just wanted to say that changing it is not stupid. ;) Moritz Grimm <[EMAIL PROTECTED]> wrote: > But keeping confidential files on "true" multiuser systems is > stupid ... > IMNSHO. And you cannot hide anything from the administrator. You > depend on how well the admin is capable of securing the rest of the > system and not have it rooted by a 3rd party(*) including the other > users. But if you can depend on root, then it's useful. I don't mean top secret files, I mean private files noone else should read, like mail or letters for example. All in all, I just wanted to say that it's not stupid to secure the homes, not more but also not less. -- Jonathan
Re: suggested /etc/skel/ modifications
Quoting Hannah Schroeter <[EMAIL PROTECTED]>: > Hello! > > On Thu, Jul 28, 2005 at 06:50:19PM +0200, [EMAIL PROTECTED] wrote: > >Quoting Moritz Grimm <[EMAIL PROTECTED]>: > > >> > Ever heart of a multiuser system where one user shouldn't be able to > >> > acces the files of another user? Not all users are thinking about this > >> > issue and many forget to change the modes for confidential files. IMO, > > >> But keeping confidential files on "true" multiuser systems is stupid ... > > >I disagree, How about a heavy build server for different projects? > >Or shared (insert word)-solutions. You cannot be to careful with your > >files, one day, as normal user, you will forget to chmod() that file ... > > Then, for that system, you can modify the default install as said. > And if your stuff is very secret, even among co-workers, check out > encryption options. I agree to modify that system for it and not to push these changes to everybody, I only disagreed the point of view being mentioned. A solutions like chmod 700 /etc/skell is good enough for me, since starting to change sources will force you to keep track of any changes to it and applying patches every time etc etc. > > However I'd prefer to work in a place where the employees could > in basic trust each other wrt the products of their respective work. Same here, this isn't true however where I'm working. Software company .. external people .. source code. > > >[...] > > Kind regards, > > Hannah. > > This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
Re: suggested /etc/skel/ modifications
Hello! On Thu, Jul 28, 2005 at 06:50:19PM +0200, [EMAIL PROTECTED] wrote: >Quoting Moritz Grimm <[EMAIL PROTECTED]>: >> > Ever heart of a multiuser system where one user shouldn't be able to >> > acces the files of another user? Not all users are thinking about this >> > issue and many forget to change the modes for confidential files. IMO, >> But keeping confidential files on "true" multiuser systems is stupid ... >I disagree, How about a heavy build server for different projects? >Or shared (insert word)-solutions. You cannot be to careful with your >files, one day, as normal user, you will forget to chmod() that file ... Then, for that system, you can modify the default install as said. And if your stuff is very secret, even among co-workers, check out encryption options. However I'd prefer to work in a place where the employees could in basic trust each other wrt the products of their respective work. >[...] Kind regards, Hannah.
Re: suggested /etc/skel/ modifications
On Thursday 28 July 2005 12:37 pm, Dave Feustel wrote: > On Thursday 28 July 2005 11:24 am, Moritz Grimm wrote: > > Dave Feustel wrote: > > >>And [snip] > > of this anecdote: A pal once had to deal with a probably-owned OpenBSD > > box, because his clueless co-admin installed an outdated, vulnerable > > MySQL server by hand (not related to ports/packages at all), and likely > > configured it in a bad way, too. Some script kiddie managed to exploit [snip] > > My point is mostly that, if you try really hard, you can make an OpenBSD > > box insecure. OpenBSD can also not help you when you run an > > OpenBSD-aware trojan as root, for example. > > > > Moritz > > Thanks. I have installed several software packages not in the > ports/packages and I realize that running "sudo make install" is not safe. > Sometimes I just run the software under my non-root login without > installing. It isn't running software that isn't in the ports system that is the problem. The problem was the software version installed had some vulnerability and it was never updated to a patched version. Not keeping up with security updates is how most systems get updated, and it can happen to any system no matter how secure the default install of the operating system is. Security is a big cat and mouse game, especially when you are a big target like say Microsoft or Google. There is no one configuration that you can say is 100% bullet-proof, it is always a moving target where you are constantly juggling known exploits and bugs, new patches, system security, and system usability (which includes availability). Tim Donahue
Re: suggested /etc/skel/ modifications
Quoting Moritz Grimm <[EMAIL PROTECTED]>: > > > > Ever heart of a multiuser system where one user shouldn't be able to > > acces the files of another user? Not all users are thinking about this > > issue and many forget to change the modes for confidential files. IMO, > > But keeping confidential files on "true" multiuser systems is stupid ... I disagree, How about a heavy build server for different projects? Or shared (insert word)-solutions. You cannot be to careful with your files, one day, as normal user, you will forget to chmod() that file ... > IMNSHO. And you cannot hide anything from the administrator. You depend > on how well the admin is capable of securing the rest of the system and > not have it rooted by a 3rd party(*) including the other users. Then you shouldn't use the system at all. It is not because something might be/become a flaw, that you don't have to care about the rest. Every extra layer of defence _does_ protect you from a subset of attacks, even how small that subset is, it counts. > If I create new users for the sake of them having a Unix > shell, then it's something different, but this is so very rare ... and > there really shouldn't be any confidential things on such a multiuser > shell server. Who says that the admin is any more trustworthy than some > other, regular users? They are not, but most of the time they give you confidential information that you must use on that box that you use for stuff other users may not access, like database/pop3 information. > > > Moritz > > *: OpenBSD had only one remote hole in the default install, but a few > more (very few, relatively speaking) local root vulnerabilities. And > there are also still numerous ways of breaking OpenBSD inspite of sane > defaults and exploit mitigation techniques in place. > > In the end, it simply boils down on properly assessing risks, giving a > box a defined purpose (even if it's an "eierlegende Wollmilchsau"(**)), > and enforcing an appropriate security and usage policy. Solving social > problems with social means is often enough the only viable way. > > **: Rough translation: A fictional all-purpose animal; a sow that grows > wool, gives milk and lays eggs. > > This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
Re: suggested /etc/skel/ modifications
On Thursday 28 July 2005 11:24 am, Moritz Grimm wrote: > Dave Feustel wrote: > >>And > >>there are also still numerous ways of breaking OpenBSD inspite of sane > >>defaults and exploit mitigation techniques in place. > > > > Is there any way I can tell whether my system has been broken as you > > describe? > > This really depends ... I can't tell specifics. I mentioned this because > of this anecdote: A pal once had to deal with a probably-owned OpenBSD > box, because his clueless co-admin installed an outdated, vulnerable > MySQL server by hand (not related to ports/packages at all), and likely > configured it in a bad way, too. Some script kiddie managed to exploit > whatever was going on there. He found out quickly because of an > /etc/shadow file and maybe some other signs, IIRC ... I suspect that the > cluelessness/idiocy of the s'kiddie, or simply the nature of the attack, > resulted in no further damage, however, he reinstalled the box anyways > and bitchslapped the co-admin. > > I'd like to be more specific, but there wasn't done any forensic > analysis of the attack, and it's been a while, too. I think it was an > OBSD 3.4 installation. > > My point is mostly that, if you try really hard, you can make an OpenBSD > box insecure. OpenBSD can also not help you when you run an > OpenBSD-aware trojan as root, for example. > > Moritz > Thanks. I have installed several software packages not in the ports/packages and I realize that running "sudo make install" is not safe. Sometimes I just run the software under my non-root login without installing.
Re: suggested /etc/skel/ modifications
Dave Feustel wrote: And there are also still numerous ways of breaking OpenBSD inspite of sane defaults and exploit mitigation techniques in place. Is there any way I can tell whether my system has been broken as you describe? This really depends ... I can't tell specifics. I mentioned this because of this anecdote: A pal once had to deal with a probably-owned OpenBSD box, because his clueless co-admin installed an outdated, vulnerable MySQL server by hand (not related to ports/packages at all), and likely configured it in a bad way, too. Some script kiddie managed to exploit whatever was going on there. He found out quickly because of an /etc/shadow file and maybe some other signs, IIRC ... I suspect that the cluelessness/idiocy of the s'kiddie, or simply the nature of the attack, resulted in no further damage, however, he reinstalled the box anyways and bitchslapped the co-admin. I'd like to be more specific, but there wasn't done any forensic analysis of the attack, and it's been a while, too. I think it was an OBSD 3.4 installation. My point is mostly that, if you try really hard, you can make an OpenBSD box insecure. OpenBSD can also not help you when you run an OpenBSD-aware trojan as root, for example. Moritz
Re: suggested /etc/skel/ modifications
On Thursday 28 July 2005 10:09 am, Moritz Grimm wrote: > And > there are also still numerous ways of breaking OpenBSD inspite of sane > defaults and exploit mitigation techniques in place. Is there any way I can tell whether my system has been broken as you describe?
Re: suggested /etc/skel/ modifications
Jonathan Schleifer wrote: This kind of paranoia adds nothing to security (~/.ssh and others that need it are already set to restrictive permissions), and there is no privacy from root no matter what. The rest is, again, personal preference and/or something about local policies. Ever heart of a multiuser system where one user shouldn't be able to acces the files of another user? Not all users are thinking about this issue and many forget to change the modes for confidential files. IMO, But keeping confidential files on "true" multiuser systems is stupid ... IMNSHO. And you cannot hide anything from the administrator. You depend on how well the admin is capable of securing the rest of the system and not have it rooted by a 3rd party(*) including the other users. Other than that, I wrote how easy it is to close down the home directories - the permissions of everything in /etc/skel, the directory itself included, propagate to new user's homedirectories. After that, things like the umask don't matter at all, because only the user him/herself and root can enter the respective homes. If I, as the admin, want or have to hide things from the users, then that's fine and not related to home directory permissions. Stuff like /etc/ssl/private. Other than that, I create new users for them to be able to work together, or with my own regular user account. Or, I create new users and give them certain administrative rights on a special purpose box. If I create new users for the sake of them having a Unix shell, then it's something different, but this is so very rare ... and there really shouldn't be any confidential things on such a multiuser shell server. Who says that the admin is any more trustworthy than some other, regular users? Moritz *: OpenBSD had only one remote hole in the default install, but a few more (very few, relatively speaking) local root vulnerabilities. And there are also still numerous ways of breaking OpenBSD inspite of sane defaults and exploit mitigation techniques in place. In the end, it simply boils down on properly assessing risks, giving a box a defined purpose (even if it's an "eierlegende Wollmilchsau"(**)), and enforcing an appropriate security and usage policy. Solving social problems with social means is often enough the only viable way. **: Rough translation: A fictional all-purpose animal; a sow that grows wool, gives milk and lays eggs.
Re: suggested /etc/skel/ modifications
On Thursday 28 July 2005 08:00 am, Jonathan Schleifer wrote: > Moritz Grimm <[EMAIL PROTECTED]> wrote: > > This kind of paranoia adds nothing to security (~/.ssh and others that > > need it are already set to restrictive permissions), and there is no > > privacy from root no matter what. The rest is, again, personal > > preference and/or something about local policies. > > Ever heart of a multiuser system where one user shouldn't be able to > acces the files of another user? Not all users are thinking about this > issue and many forget to change the modes for confidential files. IMO, > it's not paranoid, but useful. On a singleuser system, it might not > matter, for example on your desktop. On my desktop, I don't have 700 > either. But on my server, it's very important for me to have 700. This is fairly easy to customize since the adduser command is just a perl script. (Hint: I believe that line 1143 in 3.7 might be a good place to start looking.) Tim Donahue PS. See http://www.openbsd.org/faq/faq4.html#site for an easier way to distribute this change when you are installing.
Re: suggested /etc/skel/ modifications
Moritz Grimm <[EMAIL PROTECTED]> wrote: > This kind of paranoia adds nothing to security (~/.ssh and others that > need it are already set to restrictive permissions), and there is no > privacy from root no matter what. The rest is, again, personal > preference and/or something about local policies. Ever heart of a multiuser system where one user shouldn't be able to acces the files of another user? Not all users are thinking about this issue and many forget to change the modes for confidential files. IMO, it's not paranoid, but useful. On a singleuser system, it might not matter, for example on your desktop. On my desktop, I don't have 700 either. But on my server, it's very important for me to have 700. -- Jonathan
Re: suggested /etc/skel/ modifications
Mh, I just deleted some text I wrote to 1) and 2), because most if it was already said. It boils down to "personal/administrational preference and/or policy", "the current defaults are just fine and logical" and "trivial to change". Dave Feustel wrote: Also modify adduser so that the home directory permissions of new users are set to drwx-- instead of drwxr-xr-x chmod 700 /etc/skel No real need for changing any scripts, and besides, home directories with a default mode of 700 would *really* annoy me. "Grab foo.txt fom my home direc... oh, wait, sorry - I have to log in and throw it in /tmp or something." This kind of paranoia adds nothing to security (~/.ssh and others that need it are already set to restrictive permissions), and there is no privacy from root no matter what. The rest is, again, personal preference and/or something about local policies. Moritz
Re: suggested /etc/skel/ modifications
On Wed, Jul 27, 2005 at 06:11:52PM -0500, Dave Feustel wrote: | On Wednesday 27 July 2005 04:23 pm, Paul de Weerd wrote: | > On Wed, Jul 27, 2005 at 12:13:01PM -0500, Dave Feustel wrote: | > | 1) add the line | > | umask 077 | > | to .profile | > | > This breaks certain ports (as I found out the hard way) | | I was wondering about that. Which ports broke? devel/jdk/1.4 comes to mind. I bet there are more, possibly some that break in very subtle ways that I did not notice before I reinstalled that particular system. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: suggested /etc/skel/ modifications
Dave Feustel wrote: > 1) add the line > umask 077 > to .profile > > 2)add the file .kshrc containing at least the line > set -o vi > > > Also modify adduser so that the home directory > permissions of new users are set to drwx-- > instead of drwxr-xr-x OpenBSD is a general purpose OS. There are lots of general purposes out there. :) All three of those are personal preference things. You want them that way, someone else might be much more interested in "sharing" files between users rather than keeping files completely private by default. These changes would break many people's expectations, and with the exception of the last, are EASILY implemented with a siteXX.tgz file. The last one could be more generally addressed with a adduser.local script. Of course, you could also just make a wrapper script that does whatever you want to do to the users...which is probably even more general. For many apps, there are a LOT of things you might want to do that adduser(8) doesn't cover, a custom script is probaby the best choice. Nick.
Re: suggested /etc/skel/ modifications
On Wednesday 27 July 2005 04:23 pm, Paul de Weerd wrote: > On Wed, Jul 27, 2005 at 12:13:01PM -0500, Dave Feustel wrote: > | 1) add the line > | umask 077 > | to .profile > > This breaks certain ports (as I found out the hard way) I was wondering about that. Which ports broke? Thanks, Dave
Re: suggested /etc/skel/ modifications
On Wednesday 27 July 2005 04:23 pm, Paul de Weerd wrote: > On Wed, Jul 27, 2005 at 12:13:01PM -0500, Dave Feustel wrote: > | 1) add the line > | umask 077 > | to .profile > > This breaks certain ports (as I found out the hard way) > > | 2)add the file .kshrc containing at least the line > | set -o vi > > Better to export VISUAL=vi in your .profile if that's what you prefer. > I don't think it's a good idea to change this default for all users - I think that emacs editing mode can also be specified via the set option. > not everyone loves vi that much, some people find it annoying on the > commandline. Those people that prefer there shells in vi mode have the > option to export VISUAL=vi or set -o vi. > > From a wet What The Hack, > > Paul 'WEiRD' de Weerd
Re: suggested /etc/skel/ modifications
On Wed, Jul 27, 2005 at 12:13:01PM -0500, Dave Feustel wrote: | 1) add the line | umask 077 | to .profile This breaks certain ports (as I found out the hard way) | 2)add the file .kshrc containing at least the line | set -o vi Better to export VISUAL=vi in your .profile if that's what you prefer. I don't think it's a good idea to change this default for all users - not everyone loves vi that much, some people find it annoying on the commandline. Those people that prefer there shells in vi mode have the option to export VISUAL=vi or set -o vi. >From a wet What The Hack, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: suggested /etc/skel/ modifications
Quoting Dave Feustel <[EMAIL PROTECTED]>: > 1) add the line > umask 077 > to .profile > > 2)add the file .kshrc containing at least the line > set -o vi > > > Also modify adduser so that the home directory > permissions of new users are set to drwx-- > instead of drwxr-xr-x > > I agree with including a configurable solution for #3. #1 however would break a lot of software installations etc. #2 would also be subject of personal preferences imho. This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
suggested /etc/skel/ modifications
1) add the line umask 077 to .profile 2)add the file .kshrc containing at least the line set -o vi Also modify adduser so that the home directory permissions of new users are set to drwx-- instead of drwxr-xr-x
