You are not logged in.
Pages: 1
I looked in this file and found some interesting things that Arch devs appear to have made default, and I'd like to know why this is? ![]()
# Disable packet forwarding
net.ipv4.ip_forward = 0
# Disable the magic-sysrq key (console security issues)
kernel.sysrq = 0
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1All three of these I'd like to hear the background on.
The SYSRQ key is disabled here? Wow, no wonder I've been having trouble getting it to work ![]()
Seriously though, security issues? Are we talking about these concerns? Do Arch devs not agree with the counter-point there?
Disable TCP SYN cookie protection -- isn't that a good thing? Does it slow some stuff down, then?
And then disabling packet forwarding... doesn't really hurt anyone who want that, and therefore would be able to figure out how to turn it on, but official word would be nice.
Last edited by Ranguvar (2009-12-31 03:27:34)
Offline
The SYSRQ key is disabled here? Wow, no wonder I've been having trouble getting it to work
Seriously though, security issues? Are we talking about these concerns? Do Arch devs not agree with the counter-point there?
That does not discount sending the escape codes by other methods, and whatever reasoning justifies its inclusion would also have to apply to granting users power access, which is a conundrum similar to this one, except sysrq is even more potentially harmful.
Disable TCP SYN cookie protection -- isn't that a good thing? Does it slow some stuff down, then?
It's being enabled, not disabled.
Offline
I'm with Ranguvar on the SysRQ thing, even though it's pretty easy to enable. It's not equivalent to granting users power access, because you need physical access to the computer to use it. And if I have physical access to a computer, I can always rip the plug out of the socket even if I don't have the right to restart it. I'd way rather some guy do Alt+SysRQ+{R,E,I,S,U,B} than that.
One case against it would be if people set up arch as a thin client in a public kiosk. Giving the public keyboard access shouldn't necessarily give them all the power that magic SysRQ provides.
Offline
sysctl is a part of (UNIX) kernel, don't know one don't touch the other. Simple. Not to mention that all is available on the net. Wiki argument is not great, why not to run OS without security at all? There is no way to 100% protect box, so what is the point settting any protection at all?
Of course syncookies must be first enabled in kernel for sysctl command to work (by default in vanilla this is disabled), magic syskey can also be disabled in kernel and then whatever you do this option is gone.
sysctl gives easy way to control these features. It always amazes me that people have no idea about sysctl claiming at the same way that customization and security convinced them that linux is superior to windows.
default settings in sysctl.conf are remnants of good OBSD policy: everything is disabled, enable onlywhat you need. The opposite is windows policy: everything is enabled, disable what you don't need. Latter is much mode difficult to control.
I like sysctl because it gives so much control over disk performance (including fine tuning of fs), network, memory handling and obviously kernel based system hardening.
sysctl is so well described, than everybody can easily learn how to use it.
It's not equivalent to granting users power access, because you need physical access to the computer to use it.
magic sysrq is used for remote reboot for example (need to install ipt_sysrq).
On the other hand, disabling magic sysrq in sysctl.conf is not safest option because there is some periond of time before sysctl.conf is read so disabling in kernel config is better option from security standpoint
Offline
I guess those settings are the minimum sane settings to have while not trying to do too much for the user. The sysreq thing .... if anyone does Alt+SysRQ+{R,E,I,S,U,B} then it is ok but imagine anyone can use it and skips a few steps like Alt+SysRQ+{R,B}, it is even worse than the change in xorg (to disable ctrl-alt-bksp by default).
As for enabling syn cookies protection and disabling ipv4 forward it seems ok to me, I'm not as expert on the matter though but all iptables configuration guides for home users mention enabling syn cookies protection and disabling ipv4 forwarding among other things.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1