Hi,
I haven't spent too much time thinking over this so there's probably a hole in the idea - but what about having servers with ID's? Then rather than rpm' ing everything onto a server, you could instead "gcc" build from source the OS and built into the binaries would be the server ID - this ID would be given at time of installation and would be hardwired into the motherboard. Then all the software running could be verified in some way, perhaps in a way that the software never knows what the server ID is , but only that if the ID built into its binary is "correct" or "not correct". Then no hacker could replace your core binaries - because the system would not run them because they don't have the server ID hard coded into their binaries. Would something like this be possible? What about server serial number?

Or alternatively categorising core binaries into 2 groups. Those that can be modified by superuser and those that can only be modified by superuser with a secondary security password that is not stored on a file but in some kind of Hardware. This hardware never gives out the password it only says if what was entered is "right" or "wrong".

if the server could be compromised could it not be emulated?

actually this would work. It would need to be a hardwired security password. Some kind of addon to a motherboard that would hold the password in its own ROM memory and would only ever verify that a provided password by the system was either "correct" or "incorrect". If as the owner of the server you needed to update the password you could remove the hardware and plug it into something that can alone change the password.

This would then nullify any hacker completely. All that needs to be done is to make OS work so that it only executes core binaries if they have the password built into their binary.

You could make it so only the main core binaries would require this building from source with this special password built into their binary. This would then mean you don't have to keep doing OS Re-installs and that you could trust the core binaries. Only the server owner would know the server Id password held in the addon hardware ROM device. So no hacker could emulate this because they wouldn't know this password and couldn't crack it because the device would be hardwired to only give a "correct" or "incorrect" responce to the system.

seems like a big undertaking.

they have something similar for windows on thinkgeek.com i believe

not sure how it works as the details were a little sketchy.

I always wondered what would happen if you somehow encrypted the FAT with a physical key. performance might suffer but it seems like a decent idea.

This is what shadows does. If you take a close look to it, shadow never "unshadows" a password, it merely shadows the entered password and checks the result against the one stored in /etc/shadow. So that Idea is great, and unbreakable... except, of course, by brute force.

Take this as a thurth. There will always be a way to break or work arround a security messure. That's why hackers keep innovating... for both, finding and fixin holes and vulnerabilities.

Ok... how would you build the binary? with a modified gcc (say)... and if any hacker got root access... couldn't he compile his own program with the same gcc?

Ok, giving a correct / incorrect answer is the same shadow does... and shadow is one of the safest codings ever written...

Now...I think it is a great idea... it could grow to be some multimillionaire software... you should get a team and start working on it before some big enterprise undertakes the project...

I'm not exactly sure how this would all work, I'd have to sit down and think it over some more, but basically when compiling core binaries, gcc could have a built in option - compile with server ID: xxxxx, or something (only the owner of the server knows this server ID). The OS would only execute the core binaries that have the password embedded in them, any hacker attempts to execute their own compiled core binaries would be useless as the system wouldn't execute them, wrong or no server ID password in their binary, which the OS would require.

The only really difficult thing would be having to install these ROM devices (that hold the pasword) in each server, maybe you could make them like a PC card that you can buy and put into one of the motherboard slots. Or even better a new slot could be added to the front of servers, you could put in like a smart card or something (like for foxtel boxes) - slide it in the front, and thats the ID for the server. Maybe they could give these ID's to hardrives or like my original idea they could be on the motherboard.

My basic idea is you have to have a way for software to be unique to each server. The reason there are so many security problems these days to my mind is because everythings shared, the same, duplicated, copied. Software needs a way to be unique on each server. I think the idea of a server ID can support this. Every server is unique and identifiable, all software (well all core binaries) would also be unique and identiffiable and would only work on the server they are compiled on.

I guess this would put an end to rpm's

Unfortunately I don't have the time really to develop this, nor the finacial backing, I just hope some Linux programmers have this idea brough to their attention. As a web host provider and system Admin I've had servers hacked and OS reloads, migrations, etc, its got me thinking of solutions.

It's like applying a PGP signature for each core binary on the server... only that the pgp key is stored in a piece of hardware... Like a USB ROM?

You're idea is extremely similar to what Microsoft and Intel wanted to design with "Palladium" (see this link). Instead of the server signing the binaries and you trusting the server (which would be nearly unmanagable since most software is distributed as binary, not source) the developers would sign the binaries that they distribute and you would trust the developers.

Ultimately some kind of hardwired trust model seems to be where security is headed, but what has been proposed so far was just unreasonable. The biggest problem is "who would be the Certifying Authority?". As I mentioned above, having to build all components of your system from source every time you install or upgrade it is just not reasonable. When you talk about large enterprises and hosting companies that deploy hundreds of thousands of systems, you cannot be taking hours or days to compile the software on each machine.

Can binaries be updated? Could installation software update and add a server ID key into the raw binaries? Or could a Distribution of Linux be developed to allow this adding of a server ID key into the raw binaries by installation softrware?
This would then solve the building from source problem. Would this be possible?

Like develop a new kind of binary file that's only say 95% complete in its compilation, with random sections still uncompiled?? Then the installation software could complete the last 5% of compilation and in that last 5% include the server ID password key??? I don't know - just an idea. One thing - this server ID needs to be hidden carefully in the binaries or hackers could possibly find a way of extracting it maybe? Perhaps each Server ID ROM device could come with a unique encoding table or something ??? Which could be used to protect the binary?

Whatever....., I see that a physical ID on the server Hardware is the way to go for security in the future. Because this could only be accessed by those in immedaite contact with the server. Suddenly internet hackers would be handicapped completely.

Actually even another idea to simpify everything. Get a culture started of Having Linux OS running from Read Only Optical Drives (or large ROM Chips of some kind) on servers with each distro having a burned root password (permanent)? If you wanted to upgrade your distribution then the only way you could would be via a new CD or ROM update (using server Id password). Kind of like OS chips, or LInux in a bottle - like rescue CD's. You'd still have a writeable hard drive, just the core OS files would all be loaded from the optical drive or ROM. To upgrade you could simply download the next distro from net and burn CD or update ROM with special server ID password, stored on the ROM. Yea this is a good idea - separate the OS files from other files. Alway have OS on READ ONLY devices. Hey this is a pretty simple solution, why aren't people doing this more? If there's a bug in the OS kernal or something then you'd have to burn a new CD - (costs $1?) or update ROM.