Find the answer to your Linux question:
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 23
Well mounting my MyBook is only possible with the UUID's, the dev's don't work as I said And as I said you should use labels . I didn't ask you ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Linux User Manko10's Avatar
    Join Date
    Sep 2010
    Posts
    250

    Well mounting my MyBook is only possible with the UUID's, the dev's don't work as I said
    And as I said you should use labels. I didn't ask you to use the raw device names.
    And what do you want to do with /tmp? You can't remove the sticky bit, otherwise this folder would become useless. Also removing the execution rights is meaningless because that controls the browsability of folders. Putting it onto another partition and mounting it with noexec could secure your system a bit, but it could also hinder some applications working properly anymore. You should rather make sure you don't have any security holes in your programs.
    In respect of the rights you should give the user and users options only to partitions which need them. And of course you should use native file Linux systems for best user rights management.
    Last edited by Manko10; 12-05-2010 at 10:33 AM.
    Refining Linux Advent calendar: 24 Outstanding ZSH Gems

  2. #12
    Just Joined!
    Join Date
    Aug 2010
    Location
    Amsterdam, The Netherlands
    Posts
    33
    Quote Originally Posted by Manko10 View Post
    And as I said you should use labels. I didn't ask you to use the raw device names.
    And what do you want to do with /tmp? You can't remove the sticky bit, otherwise this folder would become useless. Also removing the execution rights is meaningless because that controls the browsability of folders. Putting it onto another partition and mounting it with noexec could secure your system a bit, but it could also hinder some applications working properly anymore. You should rather make sure you don't have any security holes in your programs.
    In respect of the rights you should give the user and users options only to partitions which need them. And of course you should use native file Linux systems for best user rights management.
    The default is not secure, believe me, the Debian security documents clearly stated that If you don't have anything to comment on things I already stated then you might let other users comment

  3. #13
    Linux User Manko10's Avatar
    Join Date
    Sep 2010
    Posts
    250
    Why do you ask for suggestions when you already know what you want to do? And it seems you constantly skip that I didn't write raw device name but label. Those are two completely different things.

    Whatsoever, to be clear about /tmp: it is not the only folder with rights 1777. There are also /var/tmp and /dev/shm. You had to mount them all with nosuid, noexec etc. But what about security? Well, as I wrote it can secure your system a bit. It can avoid an impact of some default attacks, namely those which exploit some trivial security holes in your server daemons, web applications etc. Thus you should first of all make sure your applications don't have known security holes. What securing /tmp, /var/tmp and /dev/shm CAN'T do is protecting you from more skilled attackers. If someone really wants to attack your server this should not prevent him from compromising your system.
    On the other hand securing your temporary folders may break some applications.
    If you feel like needing secured temporary folders, then just secure them, why not? But you should check if your system still works properly and you should also not think that your system would be secure now. It might be a bit more hardened but nothing more.
    Refining Linux Advent calendar: 24 Outstanding ZSH Gems

  4. #14
    Just Joined!
    Join Date
    Aug 2010
    Location
    Amsterdam, The Netherlands
    Posts
    33
    I know that about /tmp, I just stated an example of what I already found out about my configuration. There are such things as zero day exploits, you can't protect yourself against those things, unless your system is already ristrictive. With for example; SELinux, system hardening, PSAD, Fwsnort, iptables, TCP wrapper, private SSH keys, Fail2Ban... And a restrictive fstab configuration which makes quite a good default backbone for security.

    So my question in this thread is: Is my fstab secure and also usable (i.e. /tmp can't be noexec because of some updates, I know that now). But what about the rest? That is where I want comments about.

  5. #15
    Linux User Manko10's Avatar
    Join Date
    Sep 2010
    Posts
    250
    Is this configuration for your home computer, for a productive server or for some absolutely critical stuff?
    Refining Linux Advent calendar: 24 Outstanding ZSH Gems

  6. #16
    Just Joined!
    Join Date
    Aug 2010
    Location
    Amsterdam, The Netherlands
    Posts
    33
    Quote Originally Posted by Manko10 View Post
    Is this configuration for your home computer, for a productive server or for some absolutely critical stuff?
    If it's not too much to ask I would like to hear every aspect, so all of them.

  7. #17
    Linux User Manko10's Avatar
    Join Date
    Sep 2010
    Posts
    250
    To make it short:

    If it's for home usage, then it's enough (as long as you are not paranoid).
    If it's for a productive server it might be enough, but more crucial is that you are a skilled administrator knowing all details about Linux administration, security and the configuration of your own system in particular.
    If it's for something absolutely critical, let's say for a cash machine, then you need a hardened Linux, skills in every aspect of software security and you can't be the only administrator.
    Refining Linux Advent calendar: 24 Outstanding ZSH Gems

  8. #18
    Just Joined!
    Join Date
    Aug 2010
    Location
    Amsterdam, The Netherlands
    Posts
    33
    Quote Originally Posted by Manko10 View Post
    To make it short:

    If it's for home usage, then it's enough (as long as you are not paranoid).
    If it's for a productive server it might be enough, but more crucial is that you are a skilled administrator knowing all details about Linux administration, security and the configuration of your own system in particular.
    If it's for something absolutely critical, let's say for a cash machine, then you need a hardened Linux, skills in every aspect of software security and you can't be the only administrator.
    So what kind of configuration do you advice? What kind of extra tweaks?

  9. #19
    Linux User Manko10's Avatar
    Join Date
    Sep 2010
    Posts
    250
    You don't understand what I want to make clear. Security is a concept, not a tool. Security consists of knowledge, risk analysis, strategies and much more which enables you to purposefully take action. It's not something I can advice you universally valid. Security is also a calculation of cost and benefit. If you have a hole which is hard to fix but also too expensive to exploit, you'd probably decide to not close it because it's not worth it.
    The only advice I can give you is: educate yourself, train your skills and don't believe everything you hear.
    Refining Linux Advent calendar: 24 Outstanding ZSH Gems

  10. #20
    Just Joined!
    Join Date
    Aug 2010
    Location
    Amsterdam, The Netherlands
    Posts
    33
    Quote Originally Posted by Manko10 View Post
    You don't understand what I want to make clear. Security is a concept, not a tool. Security consists of knowledge, risk analysis, strategies and much more which enables you to purposefully take action. It's not something I can advice you universally valid. Security is also a calculation of cost and benefit. If you have a hole which is hard to fix but also too expensive to exploit, you'd probably decide to not close it because it's not worth it.
    The only advice I can give you is: educate yourself, train your skills and don't believe everything you hear.
    Ehm, okay... I didn't make this thread to hear some 'maybes'. You did say that it might be secure enough, if that's the case then what's wrong, how can I improve it? If you can only come up with advice like 'educate yourself' (which I did) and no practical examples or solutions then I can't use it, sorry. I posted my configuration here to reflect it's flaws to make it better. If it's already good and nobody has anything to append to the config, then I'm happy I did a good job :P

Page 2 of 3 FirstFirst 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •