You are not logged in.
Hiya, I've just reinstalled Arch with a new desktop and I've been setting up security on it properly for the first time, so far I have:
Set a decent password to the bootloader
Set partition mount options as in the Security Arch Security Wiki
Set Filesystem Permissions properly
Setup a seperate user to run instead of root
Setup sudo and restricted su
Set password Hashes
Setup the simple stateful firewall as in the wiki
My laptop is a simple desktop/production machine for coursework.
I'm going to deny root login from the console and restrict password attempts to 3 tries. I'm also soon going to look into some sort of filesystem monitoring like tripwire or network monitoring I can understand, and something to allow me to test for holes.
My passwords are quite long and use symbols characters, numbers, and don't mean anything.
I'm wondering about port knocking, where a series of knocks have to be done in the correct order, I'm confused however as to whether this is advisable for a personal machine like mine or if it's really just for servers and my simple stateful firewall is enough.
I also have slight confusion regarding grsecurity for kernel hardening, it has boxes on the wiki of options and configuration, but I don't understand where those changes and configurations are made to. This is assuming I choose grsecurity because I'm torn between that and SELinux because I've heard of it more.
Finally is there a better way for me to have sudo set up for this laptop other than using the ALL (ALL) setting for my user, other than root I am the only user on this machine.
Thanks,
Ben.
Last edited by Ben9250 (2011-04-18 13:34:03)
"In England we have come to rely upon a comfortable time-lag of fifty years or a century intervening between the perception that something ought to be done and a serious attempt to do it."
- H. G. Wells
Offline
It looks like you are concerned with Ethernet intrusions over physical security. Personally, I think you are pretty well covered.
I assume all outside access is via ssh. You might consider requiring public keys.
Physical security is another issue. If someone comes to be in possession of your machine, then what? You might consider whole disk encryption.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Not sure what you're saying about grsecurity but you need to patch the kernel first before you do any configuration changes (the changes on the wiki appear to be for kernel .config), or any other sysctl options (/etc/sysctl.conf) regarding grsecurity and/or PaX. Some files are in /etc/grsec too, afterwards. As a side note; I've been using grsecurity for a while now and I really like the RBAC system (though some don't, and choose to disable this). You might want to read over the wiki again.
Depending on how you maintain your system you might also want to "harden" your C{}FLAGS (usually in makepkg.conf). Most programs are smart enough to disable flags that cause problems so I tend to keep a few listed there. If you don't compile anything then don't worry about it. Not exactly sure what you meant by "production", which is the only reason I mentioned it.
Not sure about a desktop system--I have a laptop so the Simple Stateful Firewall wasn't enough but it was a good starting place. You might also be interested in Arno's firewall rules but I only recommend adding a new rule when you fully understand it.
As far as sudo, I assume you mean ALL=(ALL) ALL ?, and are you really the only user besides root on your laptop? I have quite a few ( cat /etc/passwd ). You can restrict which programs you want to be ran as certain users and certain group priv. Read: man sudoers - more notable the `Runas_Spec' section. This is very useful but can take a lot of fine-tuning if you're paranoid.
Anyway, not much help, I know, but some things to think about.
Offline
As ewaller said, physical security is also important so I would recommend encrypting your drive.
Do you run a server? Do you connect to your machine via SSH? If not, then you don't need port knocking. A simple iptables firewall will do. If you are behind a router, the router will usually block incoming connections anyway, but better to also set up iptables.
SELinux provides a lot of power (probably the most out of all MAC implementations). In your case, SELinux would probably be overkill, and will take a long time to learn how to use properly. You might want to look at TOMOYO Linux which is the only MAC implementation to be included in the Arch Linux repos. Just do "pacman -S tomoyo-tools" and you are good to go (after having read the documentation of course). It is simple to use and much easier to learn than SELinux.
I'm not sure about the status of AppArmor on Arch Linux but that is also another option.
Last edited by jnguyen (2011-04-15 06:46:43)
TOMOYO Linux: Mandatory Access Control.
My AUR packages
Offline
Thanks for the helpful replies!
When I meant production machine, it's basically a personal laptop but I do most of my university work on it (backing it up to my windows gaming machine in case I break something) It's on the wireless but it doesn't connect to anything but my home network and university networks.
Regarding the C{}FLAGS, milomouse: I maintain one of the r-studio packages on the AUR. I read the information in the wiki's and the Gentoo links, would I be correct in assuming hardening my CFLAGS would involve finding my processor and the safe ones?
With grsecurity what I meant was I didn't understand if the kernel settings given on the wiki went simply into changing some configuration file for the current kernel and then reboot and that would be job done, or if I had to recompile and install a kernel - I've tended to leave kernel stuff alone. [EDIT] However, I've done a bit more reading, I think I've answered this question for myself but I'd prefer it if someone could kindly confirm, just so I don't go and do something catastrophic: With these kernel options for grsecurity or TOMOYO, if my kernel - the standard arch one, does not already have those options set for it, then what I would have to do is use the abs to alter a stock kernel configuration using a .conf file or menuconfig, and make sure the relevant options are enabled and basically do a build like I would normally with the AUR, and then install it and alter the boot-loader accordingly to point to this altered kernel?
I'm quite liking the look of TOMOYO, it's a bit of learning for me but I'm finding it attractive how it's all set up, and the learning mode, and real-time tomoyo-queryd allowing real time alteration of the setup during updates. I'm wondering about grsecurity with tomoyo, because grsecurity is a patchset, would it be possible to use tomoyo for MAC, and then other bits from grsecurity, for example the parts that fight chrooting and linking? The reason I ask is because some pages I've read haven't been too enthusiastic about RBAC compared to other methods, but maybe that's more opinion, I don't know the technical reason it's grounded in.
Thanks,
Ben.
Last edited by Ben9250 (2011-04-15 19:12:58)
"In England we have come to rely upon a comfortable time-lag of fifty years or a century intervening between the perception that something ought to be done and a serious attempt to do it."
- H. G. Wells
Offline
Okay I think I'm making yet more progress. I can either choose TOMOYO 2.x or 1.x, 2.x is currently supported by the vanilla kernel, and simply requires installation of the tools. But for 1.x, which has better MAC, I need to patch a kernel, although there's already the patched kernel26-ccs in the AUR, which seems up to date with vanilla kernel26 looking at the version numbers, so all I need is that and the ccs-tools. So my choice is now use the AUR Kernel, Compile a kernel using abs, or do it from source. I know a lot of people will say for the sake of time and sanity perhaps just install the one already on the AUR, which I probably will do, but I'd like to give it a whack manually just so I can learn and appreciate what goes into what is already provided on the AUR - I switched to Arch for the educational value above all!
I think now my issue has changed somewhat and drifted into a new topic, so I think my queries about kernel patches/compilation should be directed elsewhere. I'm gonna mark as solved later but I'll see first if anyone comes back.
Thanks everyone, as usual I'm finding delving deeper challenging, but very rewarding.
"In England we have come to rely upon a comfortable time-lag of fifty years or a century intervening between the perception that something ought to be done and a serious attempt to do it."
- H. G. Wells
Offline
Hi Ben9250, I'm glad you found TOMOYO Linux to be suitable. Yes 1.x branch is currently much more powerful, and you can control things like networking and environment variables etc. We have just finished rewriting the official 1.8.x documentation which can be found here. I did have a [tomoyo] repository set up with binary packages for patched kernels, but have temporarily taken this down for reasons stated here. I actually only took it down a few days ago, but eventually I will have this back up.
If you have any trouble compiling kernel26-ccs, post in the forum or just drop me an email (can find it at the top of the AUR package). We also have a mailing list for any queries unrelated to packaging.
Last edited by jnguyen (2011-04-16 06:57:58)
TOMOYO Linux: Mandatory Access Control.
My AUR packages
Offline
Thanks, jnguyen, does this compile with options the same as the ARCH stock kernel? Because the standard kernel works pretty well already on my system, and for some options going through menuconfig, whilst the help is good, there are some things obviously I've got no idea about, and won't until I've been reading and playing about in this area for longer.
Last edited by Ben9250 (2011-04-17 00:11:20)
"In England we have come to rely upon a comfortable time-lag of fifty years or a century intervening between the perception that something ought to be done and a serious attempt to do it."
- H. G. Wells
Offline