Security Model Flaws

dlofnep

To avoid droning in here, let's think for a moment.

In all the high-end operating systems used today, what do you believe to be the top security model design flaws and what would you do to improve them. Take into account that your answer must not conflict with the functionality of the operating system. Your answer can be based on either a server-orientated or desktop-orientated operating system. Functionality between the two will differ so allowances for design tweaks may also differ

joePC

Network: Deploy sticky honeypots this should stop would be hackers.

Thanks joePC

joePC

I would have to say as a security model design flaw goes, it would be TCP/IP which has been exploited countless times.

Thanks joePC

Capt'n Midnight

Buffer overruns - where program code is overwritten by accepting more data than can fit in the buffer.

A lot of exploits target the area between the keyboard and the chair.

Gavin

Originally posted by dlofnep
the top security model design flaws and what would you do to improve them

Top security model design flaws ? Give me an example of what you are talking about. I don't see honeypots,tcp/ip or buffer oerflows as security models..



Gav

ecksor

I think he means a way that an operating system controls access to resources, how it authenticates users, authorises them, etc.

The answer I'd give is the 'all or nothing' approach to privilege that SUID/SGID gives to resource access in unix systems. One possible fix would be to make the programmer declare the exact resources that it will need to use at the program's startup and provide the ability to irreversibly relinquish those rights. Something similar to systrace except moving the burden somewhat. Of course, I have no doubt that many programmers would request too many resources ...

dlofnep

Ecksor, good answer.

I would have to say as a security model design flaw goes, it would be TCP/IP which has been exploited countless times.

Was I that incomprehensible?

Buffer overruns - where program code is overwritten by accepting more data than can fit in the buffer.

The design of the operating system has nothing to do with bad code. Although, A poorly designed operating system may aid the ease of privilege escalation.

I believe a segregated account system could very well make life harder for privilege escalation but it also may affect the functionality of the operating system. With a re-design of the actual o/s model, the possible functionality could be improved with a more finely grained account management design.

I am a firm believer in the fact that an application should require the least amount of privileges possible. SUID should not be slapped on an application for functionality or for time purposes.

I think the days on relying on discrentionary access control are over. Both a set of standards from load-time implemented with mandatory access control (MAC) co-existing with DAC would stop alot of privilege escalation and make alot of current flaws obsolete.

This would also aid what eksor is referring to. If there is a more finely grained resource control structure for programs, then it would greatly improve the security of a system. But I think that leaving the security of an operating system down to that of an application programmer to not be a good practice; all hail systrace.

And yes, a lack of understanding with novice programmers would involve far too many resource calls which would in turn render the whole resource declaration useless.

Just my 2 cents.

ecksor

Thanks Teach!

dlofnep

No No.. Thank you.

Capt'n Midnight

Let's take Linux or NT as examples - both can be compiled for different hardware, i386/PPC etc. - Because of the underlying differences in the archectiure and the compilers you might have different security considerations for each. The point being there is no point in worrying about rights apps/users might have when the someone can bypass all of these with a simple exploit (Box of chocolates ?).

Ok once you are sure the OS is not porus you can start worrying about trade off between usability and security. Even if you ignore security many software speedups (weak checking) have resulted in downtime for patching, recovery or rebuilding - so you could argure that security levels don't impact on overall productivity as much as benchmarks would suggest.

All apps should run in their own memory space. (Perhaps on virtual computers. In windows there is a load of junk that is allowed to run in ring 0 - not a good idea and definietly to be hopped on even if it slows things down. But it would be nice to have a list of what each needed access to - you could then rate (blacklist?) apps according to the security policy in place.

You could also take a leaf from dongle protection - frequent re authentication - fingerprint or verifyifing that smart card or whatever is still present - so if someone gets lucky the time window is as small as possible.

One lovely feature would be rollback, it's not rocket science to design an OS that records transactions. This way if there was a security problem you might be able to simply undo the damage.


Re leaving security to application programmers - I'm always reminded of the diffenence between Novell 3.x - where IIRC all the NLM's had full privilage and the Novell certified ones just kept on running and Terminal Server which could be killed by users with screwy printer settings connecting to a third party printer driver. Also programs have back doors and not all third pary programmers get security checks.