Additional Security in the Linux Kernel? 315
nyx asks: "Recently, I was looking for some way to improve security on my linux boxes. I found few linux patches like grsecurity, LIDS (now also as Linux Security Module), Medusa DS9.
I'm testing grsecurity (and it's ACLs) now and I'm quite satisfied with it, but I wonder, what are pros and cons of other solutions. Anybody tried them and can share his experience with us?"
Additional Security (Score:5, Funny)
Re:Additional Security (Score:3, Funny)
Re:Additional Security (Score:2)
Remove the floppy drive.
Re:Additional Security (Score:2)
Re:Additional Security (Score:2)
Re:Additional Security (Score:2)
And don't leave the thing logged in as root!! If they're going to make a physical compromise, at least make them work for it to increase the chance they get caught.
Re:Additional Security (Score:2)
Lock the door when you leave the computer room.
This got modded up as funny, but those of you out there who are new to network security and administration need to take note - this one is pretty fundamental.
No matter what patches you install, services you disable, firewalls you configure, or holes you plug; if I can get unrestriced (private) console access for < 1 hour, U R probly 0wn3d. I might not even need to r00t your box right away - I'll just image the hard drive to a spare I keep in my backpack and walk out with your data -- I'll have all the time I need to dig out the interesting bits later.
Encrypted filesystems *should* invalidate this approach, but we'll see.
Re:Additional Security (Score:2)
TMOUT=1800
It makes bash logout after half an hour (1800 secs) idle at the prompt. This is good if you _forget_ to lock the door when you leave the computer room. I usually have several remote terminals open on my desktop. If I step away for a few minutes to attend to something else, they start closing automatically.
Re:Additional Security (Score:2)
http://www.signaltonoise.net/library/Adv-Bash-S
I think you have a statement in your setup that you might need to alter.
Use a stylesheet (Score:2)
GRSecurity (Score:1, Informative)
zerg (Score:3, Funny)
If the NSA security enhanced your machine, would you even know about it? Suspect it?
I suggest vserver (Score:5, Informative)
You can create virtual servers on your machine, tailored for specific tasks.
For example, you can create virtual server where you'll work on your project, virtual server which will run apache, virtual server in which you'll browse web and read mail.
You then can put them on different IP addresses (or no addresses at all) and make them indepedent, changing information only by means YOU approve (shared directory, TCP sockets under firewall, etc).
It's a kernel patch and some user-mode programs.
Virtual servers can share binaries for saving disk space.
Re:I suggest vserver (Score:2, Interesting)
Re:I suggest vserver (Score:1)
Yes, it's possible that somebody hack into vserver but unless he will not done anything that
stop main kernel (like FOOF bug), he cannot get anywhere else
Firewall on child vserver is created by main vserver which is not under control from child vserver... So if hacker hack vserver - he'll get only that vserver and only that rights (including network access) that have been given to that vserver.
Moreover, main vserver can spy on child vserver
if enabled to do so.
Re:I suggest vserver (Score:2)
You cannot change your address to anything but
the list of allowed for your vserver...
Re:I suggest vserver (Score:3, Informative)
howto? Simple, install redhat7.2 on an empty disk, and copy all the files including permissions to
The vserver sources are easy to deb-make (man deb-make) (tip: "RPM_BUILD_ROOT=$(DESTDIR)" in the Makefile).
"vserver 01 start" to boot rh72, and "vserver 01 enter" to enter it as root. edit the ListenAddress in
(did I mention the whole thing is diskless remote boot too?)
forgot to mention this... (Score:2)
nsa linux (selinux) (Score:1, Informative)
adds some intresting security features, but doesnt support x so i didnt install it on my workcomputer.
Also adds the question do we trust the NSA even if the source is avalible
Re:nsa linux (selinux) (Score:2)
Where n is a number that varies depending on the computer language used, the coding styles enforced, the number of people reading the code, etc, etc, etc...
Current Project with PF_KEY (Score:2, Informative)
Re:Current Project with PF_KEY (Score:3, Informative)
Bastille (Score:3, Funny)
Re:Bastille - No Kernel Patches (Score:5, Informative)
Re:Bastille - No Kernel Patches (Score:2)
It's got some pretty good file permission changes that work very well for server environments. And yes, file permissions really do matter. Even on the simplest level it will ask you to remove SUID permissions from ping, dump, traceroute, at, etc. I know for sure there's been at least one local user -> root user exploit for dump that would be foiled if it were non-suid. There was even one this year for at which allowed the same privilege elevation on RedHat versions prior to 7.2:
http://rhn.redhat.com/errata/RHSA-2002-015.html
Of course, a good admin should go through and audit which files are SUID him or herself and kill off ones which aren't used by non-root users. But this makes it a bit easier.
And yes, removing the SUID bits does make fewer commands available to non-root users, but let's face it, do non-root users really need to be able to run traceroutes and backups from your webserver?
LSM has been included in 2.5.27 (Score:5, Informative)
Small thing... (Score:3, Informative)
Re:Small thing... (Score:5, Informative)
Back to the original question I've used LIDS, SELinux, and GRSecurity and I've found them all to have their strengths and their weaknesses. The common problem with all of them is there is usually something you forget to configure properly the first time which can really be a pain to fix. SELinux and GRSecurity both solved this by adding a toggle mode and a
With SELinux, the major advantage is that you gain a VERY flexible architecture you can use to create nearly any type of Mandatory Access policy you need. The specifications of the system make it able to use policies based on Type Enforcement (putting the bitchy SCC patent issues aside for the moment...), Role-Based Access Control, or Multi-Level Security and likely a host of other things. The drawback is that creating a policy that covers the whole system is not a trivial thing...look at the example security policy included with the distribution (http://www.nsa.gov/selinux [nsa.gov]) and you'll see what I mean.
GRSecurity is not exactly related to SELinux; they do different things. I like GRSecurity because most of its options do not require a lot of extra configuration, they don't break any existing applications (those that do are clearly marked), and they add a lot of small protections without a great deal of overhead to the vanilla kernel. Plus their ACL system is quite well-developed and extremely secure.
Ultimately I think it comes down to figuring out what you need for your box and then going with the option that will provide it to you with the least amount of interference (unless you like fixing things, of course
Adding LIDS to a firewall... / SELinux (Score:2)
Except that LIDS seems to want to be built on the machine where it's going to be run. So what if your firewall doesn't have a compiler, build environment, etc?
Perhaps I should have RTFM further, but the available time ran out.
I've also read a little about SELinux, but there appears to be one common thing about all of these security enhancements: They make it possible to have tight enforcement of a security policy, but it appears that none of them ship any sort of policies. It would be nice to have a few to choose from, and begin learning. How about a policy that's very little more secure than the pre-LSM box, with a bunch of commented options to tighten down the screws. I guess I've seen some of that with GRSecurity.
But trying to evaluate and use any of these packages for a home system turns into a massive time-sink to do properly. WIBNI Bastille would add LSM to what they already do so well? (I know, join and do it, myself. Maybe when the big-time real world projects are in control.)
Re:Adding LIDS to a firewall... / SELinux (Score:2)
What sort of problem were you having?
But trying to evaluate and use any of these packages for a home system turns into a massive time-sink to do properly.
I'd agree. I devoted perhaps three days to installing and trying the major ones last year, and it was a pain.
Personally, I settled on LIDS, which, although it is a little squirrely, has worked happily for me. But for casual users these are not ready for prime time; every time I install a new daemon I need to set up a set of matching LIDS entries so that things work properly. This isn't much of a pain for me, but for novices it would probably make their eyeballs bleed.
St. Jude Kernel IDS (Score:3, Interesting)
Re:seems that EVERYTHING (Score:2)
Stack Guard (Score:2, Interesting)
D.
Re:Stack Guard (Score:2)
VC++ 7 comes with
Re:Stack Guard (Score:2, Informative)
Um, how about libsafe [avayalabs.com]?
-Steve
Neat Security Trick (Score:5, Interesting)
Re:Neat Security Trick (Score:3, Insightful)
Re:Neat Security -- just stupid.. use a mac (Score:2)
- It's a major PITA to do any kind of remote management. While the lack of a command prompt may make it hard to hack, it also makes it nearly impossible to administer remotely (unless you resort to a VNC-like solution, in which case you are subject to all the flaws of that solution)
- Macs are expensive. Look at XServe. Look at comparable Linux servers. XServe is expensive.
- Lack of software: Mac OS wasn't traditionally a server OS, so many of the tools that we know and love in Linux and even Win32 are missing
- Mac OS 9 Sucks: Memory management, swap maangment, networking, etc. Mac OS 9 makes Windows 98 look like a reliable, stable system.
This is not to say that Mac OS doesn't have a place as a server. For applications where security is critical and remote access, cost, or performance isn't a priority, it's certainly a viable option. It's perfect for the Army: cost and performance are not issues (they have a $300 billion/year budget, and if it's too slow they can just invest in better hardware), but security is a MUST.
SElinux and MAC vs DAC, (Score:1)
Mandatory Access Control, is also a better security Model than
Discretionary Access Control, of witch is the current model of most network OS's "out of the Box"
With MAC you have policey's the control access to services,files anything and if "something' trys to access a services it must be part of the policey that tells it what it is aloud to do, if it trys something out side the policey it fails:
kind of like a firewall's deny by policey,
here is a link to some more info about it:
http://www.nsa.gov/selinux/docs.html
Nex6
Stop writing code! (Score:5, Funny)
Not funny - Sad!!!!!! (Score:2)
Re:Not funny - Sad!!!!!! (Score:2)
Snort (Score:2, Informative)
That and good ol' P.G.P.
ACLs (Score:5, Insightful)
ACLs (access control lists) are a wonderful technology, but for non-trivial systems they become an administrative pain in the @ss. In principle you would set them up and forget about them, or at least let users maintain their own, but in practice users can't maintain their own, and they will pester you to death with requests for changes.
They also tend to drag the sysadmin into office politics. E.g., Secretary A is out on vacation and Secretary B calls you and says Secretary A did not set up her ACLs correctly and would you please give B access to certain of A's files. In addition to the annoyance of having to babysit the users, there's really no correct response to such a request.
ACLs would be great on a system where everyone is a power user. In practice that usually means your home system where you are the only user, so ACLs aren't very helpful anyway.
Conclusion: wonderful technology, hope I never see it again.
BTW, I speak from personal experience, having formerly managed VAXen with their wonderful ACL implementation. I don't object to ACLs on Linux, I just don't want them.
Re:ACLs (Score:5, Interesting)
That proof is possible if are using mandatory access control or may be other security means.
So DAC are not only pain in the
Re: ACLs (Score:1)
> BTW,it's theoretically proven that security provided by Discretory Access Control systems (in which ACL's and unix protection schemes belong to) is algoritmically unprovable - you cannot deduct that system is secure based on system and DAC rules.
Thanks, I'd never heard that. Do you know whether government security certification levels take that into account?
Re: ACLs (Score:3, Insightful)
For class B and A you have to have Mandatory Access control.
Re:ACLs (Score:5, Informative)
1. The 1976 Harrison, Ruzzo and Ullman result (from "Protection in Operating Systems") pertains to "safety" in the access-matrix model. Inferences about security need to verify the implementation of the model as well.
2. The result only applies to a system where an infinite number of subjects and objects can be created. An implementation on a typical OS does not suffer from this limitation since resources of the host that are used for the digital representation are finite.
3. Their proof reduces a Turing machine to the access-matrix model, introducing a mapping between decidability and the leakage of a right in the access-matrix. Deciding whether a specific leak occurs is the equivalent, then, of solving the Halting problem. This proof, however, says nothing for a system where more specific knowledge of the system is used, where you *can* make stronger inferences. Look to the mono-operational system for a concrete, albeit impractical, example.
4. Their results hold for any model that uses an access-matrix, regardless of whether it is Discretionary or Mandatory.
Re:ACLs (Score:2)
Access matrix system do not have anything related to DAC or MAC, as you already said in your "4."
2) I didn't use 1976 Harrison, Ruzzo and Ullman result.
3) Main security problem with DAC system is that they can introduce troyans, because they generally allow changing rights between users without restrictions
MAC systems are not allowing troyans since changing rights between users is prohibited by rule system (role based etc...)
Re:ACLs (Score:3, Insightful)
2. It's true that you did not use the HRU result. If you could point to the work that you did base your claim on, it would be helpful. Alternatively, summarize the insight of the proof so we can understand the merit of your assertion.
3. Again, a statement you make borders on misleading. Your 3rd point is untrue. MAC forces labels and sensitivity designations. The actual policy is responsible for stating the information flow rules.
The trojan of your example can easily be transferred between processes with the same clearance belonging to different subjects.
Apart from that, MAC and DAC refer to *models*. Errors in *implementation* and configuration still abound, and a MAC system will not help in this case.
Re:ACLs (Score:3, Insightful)
ACLs made it really easy to give permission to only the people you wanted to, and you could totally ignore them if you didn't want to use them. I would be really happy about a similar implementation being a part of Linux and not just a patch.
Re:ACLs (Score:2)
You can't "totally ignore them", in particular when it comes to system security. ACLs allow people to get additional access to files relative to standard UNIX permissions, and that is something that needs to be checked. With ACLs, not only do I have to check whether /etc/passwd is owned by root, I also have to check whether someone has snuck in and given themselves write access to it through ACLs.
I would be really happy about a similar implementation being a part of Linux and not just a patch.
It should probably be in the kernel, but I think it should not be enabled by default because it creates security holes and because the functionality just isn't needed for many applications. Desktop users of Linux often don't need a complex permission system at all, and neither do many server applications (dedicated web server, dedicated database server, etc.).
Where ACLs will be most useful will be for Linux clients accessing network file systems that have them. That's the reason why they should be in the kernel, but they should be enabled only for specific file systems. But in that case, ACLs are there for interoperability, not for additional security.
NFS (Re:ACLs) (Score:2)
So unless you have a completely homogenous network there is currently no way to my knowledge that you can use ACLs across machines via NFS.
As already mentioned, ACLs give users working in groups more flexibility to share file access, rather than having the admin create a new group for each new permutation. They don't really enhance security.
Re:NFS (Re:ACLs) (Score:2)
Obviously, in order to be useful for a networked file system, the ACL APIs you need to support on the client are those required by the network file system used by the server. Those can be different from the ACL APIs either used by the local file system or by the server's file system. Take a look, for example, at what AFS does (I'm not endorsing it, merely pointing out what it does).
Re:ACLs (Score:2)
ACLs just make things much more complex, in many cases unnecessarily so. And it certainly doesn't make things more secure.
Re:ACLs (Score:2)
Re:ACLs (Score:2)
The traditional UNIX user/group system requires some advance thought and effort in setting up groups for an organization. That leads to a more manageable set of possible permissions.
ACLs are an important check-list item for Linux because there are some people who swear by them. But I also hope that as a system manager, I will never have to deal with them again--I think they are much more trouble than they are worth in the real world.
Don't forget (Score:1, Interesting)
Running applications in a chroot'ed environment is also helpful. A bit hard to setup, but once you do it, no problems.
Use tools such as iptables to restrict access. For instance, if you know that all your connections will come from *.host.com, change the rules accordingly.
Kernel patches are ugly. They try to get at the root of the problem, but they miss it completely.
The point is that vulnerable code is written by bad coders, who for some unknown reasons think that C is the best language in the universe. Clearly, they can't handle the power that C gives them and should use languages that provide memory handling for them.
If you don't mind proprietary stuff... (Score:2, Informative)
User Mode Linux (Score:1)
Re:User Mode Linux (Score:2, Informative)
I tried to use vserver patch for Mandrake 8.2 on
P1-200MMX with Apache, DNS, Mozilla, X and it worked perfectly.
Grsecurity Patch & Debugging Your application (Score:1)
Other than that it works like a charm.
use only trusted code (Score:3, Informative)
But on the other hand, you know what idealism is ...
Re:use only trusted code (Score:2)
1) All the code in OpenBSD is bugree. the recent OpenSSH hole shows this isn't the case. I'm pretty sure OpenSSH was fairly heavily audited too, and it still had a hole. The new permission separation code can help here, but OpenBSD still had a remote root exploit.
2) You NEVER have any code running thats not in the default install. Means no Apache (which had a quickly patched hole recently), no configuring your system, cause as soon as you do, you're running other code. eg. you can configure telnet to run when it wasn't running in the default install. You can misconfigure OpenBSD just as easily as any other UNIX, it just starts with safer defaults.
Code audits are like perimeter locks. It stops people from getting in. Security models are more like internal locks and safes. Once you get in, it limits what you can take. They aren't mutually exclusive.
regarding grsecurity (Score:1, Offtopic)
There is something almost treasonous about a linux kernel hack whose documentation's primary format is msword+ppt. Particularly when the html links are broken.
ACL's in Red Hat Limbo beta (Score:5, Interesting)
Read about it in the RELEASE-NOTESe ta/limbo/en/os/i386/RELEASE-NOTES [hawaii.edu]
ftp://videl.ics.hawaii.edu/mirrors/redhat/linux/b
MacOS far more secure than LINUX, proof is BugTraq (Score:1, Interesting)
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name.
Other than that event ages ago, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack.
Not one. And that includes Webstar and other web servers on the Mac.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS.
BugTraq concurs.
Re:MacOS far more secure than LINUX, proof is BugT (Score:2)
2) No Root users? Bzzz...every user is a root user. This means if/when exploits do happen, the ability for them to ALWAYS be fatal is ALWAYS there.
3) The #1 biggest reason why remote exploits will be rare. This, and only this, is the primary reason.
4) Moot issue since pascal strings minimize that vast majority of these issues to begin with.
6) Pretty much every real OS has this concept. Mac is hardly alone.
7) True, being a minority does help. Other OS's play header tricks too. On the other hand, this also means much fewer selections in available applications which mean odds are automatically reduced in the number of possible exploits. Basically, zero applications means zero odds of being exploited. I think you can follow the logic from there.
8) Security through obscurity can sometimes help but rarely is the solution. In fact, history proves that this often creates more problems than it fixes because fewer eyes ever see enough code to fix it before it becomes a problem.
grsecurity (Score:3, Informative)
When it works.
I've been trying to run it on an SMP Xeon for a while now, and any time the machine exerts itself I have to go hit the big red button. And it's not really a machine I'd like to do "testing" on, so no, I won't help with debugging. What "testing" I've done so far has been nothing but infuriating.
Another few tidbits: all the security in grsec basically completely prevents any JVM from running at all. Ditto UML. (Though UML may also have issues with SMP. But now that I've removed a big variable in my equation of horror...)
Since Rusell Coker has package SELinux for Debian, I will definitely have to investigate that sometime in the near future. I think I'll rack some uptime first to bolster my self esteem.
Re:grsecurity (Score:1)
That's how I fixed it on my Grsecurity system.
Re:grsecurity - fnk kernel tree (Score:2)
Basically this guys motivation is security and stability. He puts the whole lot through a barrage of tests, and makes sure things work, or at least determines if there is a problem and makes note of it.
Systrace for *bsd (Score:3, Interesting)
Systrace eliminates much (but not all) of that initial trial period with a method of analyzing processes and watching what permissions for what resources they need and generating ACL's based on 'normal' use. This interactive mode ~greatly~ simplifies the otherwise length process of configuring the kind of security modules being discussed.
LIDS does a good job (Score:1, Informative)
LOMAC - Perl tainting for Linux (Score:3, Interesting)
This has real potential for locked-down servers, kiosk systems, etc. It's a bit stringent for most desktops. But it's not too hard to use.
debugging security patches (Score:2, Interesting)
Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)
BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.
BSD is concerning itself with kernel security (Score:2, Informative)
I don't know the facts about Linux, specifically, but there is a push in the *BSD world for kernel security features to be incorporated as defaults.
The only one I recall off the top of my head is "non-executable stacks" to keep stack overflow attacks from being quite as easy. I'm sure it has other advantages, as well.
All this does is "raise the bar" for attackers. I'm assuming most of the Linux kernel security tweaks do the same.
Re:BSD is concerning itself with kernel security (Score:2)
Re:BSD is concerning itself with kernel security (Score:2)
Solaris has had this ability since 2.6, but you an bypass this [secinf.net]. I'm not so sure you could do this with a remote exploit tho, it seems you may need soem code running locally, so it would help agaisnt remote exploits, but not local.
LIDS != LSM (Score:2, Informative)
I am surprised noone's mentioned it yet (Score:2)
chflags/chattr (Score:3, Informative)
With standard commands like chflags (BSD) or chattr (Linux), you can mark files and directories read-only (immutable) or append-only.
The point is that once you have a working system, and if you have local access to the console, you can set proper attributes to all your files.
You then have the concept of "security levels". Once your box is in multi-user mode, the "security level" can increase, and a lot of thing will be refused by the kernel : changing firewall rules, access to kmem, to raw devices, etc. and changing extended attributes.
So even if an attacker gets root access on your box, he won't be able to alter anything except some ever changing files (something that can be solved by using an NFS mount) . And the append-only log files are really nasty, because he won't be able to hide what he's doing. Patch your favorite shells to always log history files to an append-only file to get even more fun.
On a properly configured box (that you have console access on), you must be able to run "rm -rf
Re:chflags/chattr (Score:2, Interesting)
The kernel runs with four different levels of security. Any super-user process can raise the security level, but no process can lower it. The security levels are:
-1 Permanently insecure mode - always run the system in level 0 mode. This is the default initial value.
0 Insecure mode - immutable and append-only flags may be turned off. All devices may be read or written subject to their permissions.
1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems,
2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''.
3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted.
Not specific to FreeBSD (Score:2)
Re:chflags/chattr (Score:2)
I may have misunderstood chrysalis, but the attributes can only be changed in single user mode. So you absolutely have to have local console access to set (or change) the attributes. But at that point you've got physical security issues which outweigh any sort of ACL/attribute-based protections you have.
I wonder (Score:4, Interesting)
or shadowing techniques in Linux?
What I mean:
File aging:
- If you don't use file for a week and you are now using it - that access to file go with a warning.
- If you don't use file for a half year - your appication becomes terminated with diagnostic
"File aging security access denied - file xxx"
So programs that do anything unusual that you don't do regularly on your computer will be catched.
File shadowing:
- You can introduce a mask for a project so you'll not see any files that this project has no relation to
and
- Files that are not related to any project and not system accessed becomes removed to special storage. You then will not see that files in ls.
If you access that file... then we go to file shadowing behavour...
Is there anything similar developed?
To complete the picture (Score:2)
SE Linux anyone? (Score:2)
My LIDS experience: thumbs up (Score:2)
I've been using LIDS on various machines for between one and two years. It provides thorough protections which can make it harder for an attacker to compromise your machine and/or avoid detection.
It does require an investment of time to get configured correctly. Essentially, it takes privileges away (the ability to bind to network ports, for example) and they must then be re-enabled for the specific programs that need them. Those programs must also be protected from write access to avoid an attacker modifying them to gain their privileges.
Once configured, many of the standard ways that an attacker who gained access would elevate to root or modify system files are removed, and attempts to break security are logged. I have also found that it prevents some network attacks from working (e.g., wu-ftpd buffer overflow with the RH 6.2 default (vulnerable) version); this isn't (so far as I know) an advertised capability so I took it as a bonus.
The biggest problem with LIDS is that it protects inodes, and needs to be manually kicked when file inodes update. So, for example, you can make your logs append only, grant logrotate the ability to rotate them, and then lose your append protections because the new log file has a different inode.
In summary: Definitely an improvement in security, takes an investment of time to learn and configure, may impose administrative burden if used on a large number of hosts. Very useful for defending important or Internet-accessible resources (e.g., DMZ machines).
I swear by LIDS (Score:2, Interesting)
I recompiled the kernel with LIDS, and turned off all the capabilities in the kernel, granting them on a program-by-program basis to the processes that actually needed them. In all, the lids.sh is probably 70-80 lines long (including comments) to get a fully functional webserver that allows Apache, inbound ssh, and outgoing email (for automated logging, just for grins.)
It has been the target for attacks since it was put online. About ten script kiddies a day try to get in, and one or two clueful and determined individuals a day. (I'm not counting automated worms, etc, which aren't worth meantioning, given that most are looking for IIS and friends.)
Thus far no one has gotten close, due mostly to the lack of available entry points (significant inbound and outbound IP restrictions.) However I gave the root password to a few associates and told them to break the system and they were unable to do anything interesting whatsoever, including even modifying the web content.
If I had to do it today, with more options available to me, I'd give SELinux a whirl as well, but LIDS is still top notch - I don't have a single complaint.
SELinux is the solution for the paranoid (Score:2)
Some kind fellow was running an SELinux box with a guest root account.
The account was powerless. SELinux is a paranoid sys admin's dream. You have to specifically grant ifconfig permission to see properties on each interface. Ping needs raw sockets access granted for each interface it wants to send pings over. etc.
Absolutely necessary (Score:2, Interesting)
The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary.
For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges.
If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges.
Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?
One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.
Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough.
What if I need to run some other application?
An Operating System should be able to protect data even in the case, that an application gets hacked.
Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.
LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.
Re:It's a bit of a challenge, and one to be avoide (Score:3)
C, a language that provides no security features such as garbage collection
In what sense is garbage collection a security feature? That makes no sense.
It is a very sad fact, but logically Microsoft's programmers are smarter than those in open source, simply because they're able to earn more money
That's not true at all. As someone who makes their living programming I can tell you that there are plenty of dumb commercial programmers and plenty of smart open source programmers. And vice versa. If you really wanted to be "logical" you'll understand that money earnt is not the same as skill. Plenty of people do highly skilled work without payment - ever heard of a hobby?
go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Like I said, blatant troll.
Re:It's a bit of a challenge, and one to be avoide (Score:2, Interesting)
Er... or Apple?
Yeah. Or, for that matter, RedHat.
And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.
So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.
If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.
You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.
Re:It's a bit of a challenge, and one to be avoide (Score:2)
In what sense is garbage collection a security feature? That makes no sense.
It's not garbage collection as much as direct memory access and management. In C, it's very easy to accidentally write something that allows for the execution of arbitrary code. In Java, it's very hard.
This is similar to the way one should write banking code. For most of the programmers, there should be no way to add money to an account or remove money from an account. Instead, you just give them an API that allows transfers. That way you eliminate a whole class of possible errors.
The OP's confusion probably comes from the fact, that once you remove free(), garbage collection is the common solution.
The less you know, the more money you make. (Score:2)
- time = money
- knowledge = power
- power = work / time
- knowledge = work / money
- knowledge * money = work
- money = work / knowledge
- therefore, as knowledge --> 0, money --> infinity!
QEDSecurity != Security? (Score:2)
Userspace hardening (e.g. Bastille) is another.
Virtual servers sounds like an interesting approach as well (virtual servers running a grsecured, hardenend system anyone?)
But, security for things like web services do not end with kernel patches or even userspace hardening utilities.
As [...] noted here, the 'security' of Slashdot's moderation system has been shot to hell (astroturfers of various ilks, most commonly but not exclusively Microsoft paid lackeys, and outright trolls are posting at +2 and being granted moderator priveleges on a daily basis). As to whether the above troll you reference was moderated up by trolls, Microsoft Astroturfers, or a combination is anyone's guess.
The fix is obviously for the slashdot editors to begin creating a web of trust in a similar fashion to how GPG/PGP keys are managed (complete with revokation if that trust is abused). Initially only the slashdot moderators and some well known friends of theirs would be in the ring of trust, then gradually others (based upon posting content, relationships, what have you). This would at least allow the Astroturfers and trolls to have their moderation and/or +2 posting priveleges removed when they do occasionally slip through.
In the meantime, until such an approach is taken, I'm afraid the astroturfers and trolls will continue to abuse the moderation system for the foreseeable future. Numerical benchmarks such as karma simply do not cut it when trying to filter for quality of content, discussion, moderation, and meta-moderation.
Slashdot security in a discussion of security now rates a -3 Offtopic?
So, by pointing out that security for a web server doesn't stop at kernel patches, and pointing to a real world example to underscore that point (this very site), the comment is somehow now offtopic? I think this thread makes the aforementinoed example even more pointed than it already was.
Or is self-criticism now a taboo subject on this forum? Remarkable.
Re:Simple security improvements (Score:2, Funny)
all the above steps.. maybe not in that order
actually yes (Score:2)
to this end you can use a mac
(big endian so defeats alot of stack smashing targeted at x86)
use bsd
(THE network stack -problems in MS TCP/IP stack have been solved years ago in BSD)
and dont run any silly daemons
http://www. [bastille-linux.org]
does a nice job of sorting out things config wise where most problems live
regards
John Jones
Re:FUD alert! (Score:2, Interesting)
I won't rehash the manyfold reasons you're wrong about those assertions (it's been discussed to death already), but I will point out that you're wrong, and you're just trolling. Knock it off.
Besides, while Linux's security is excellent, it can (and should) be improved. It's good, but by no means perfect. (It's much better than anything M$ can put out, though.)
Re:security (Score:3, Informative)
The TrustedBSD project provides a set of trusted operating system extensions to the FreeBSD operating system
In other words, it's not an OS, it's a set of patches and extensions... please, check your facts before you post something.