Third Linux Question

Quote:

---

What: How can I restrict any number of client applications on a large-scale system, so that incoming data cannot be executed nor can it read or written to beyond the application’s sandbox?

Explained: The point here is to restrict all incoming data in a manner that malware is automatically incapacitated. I would like to do this without creating thousands of extra user accounts (since cache data and other application data must remain private) for each user’s applications.

Why: anti-virus tools can only respond to what they know, if this data is locked down in a manner that makes unknown code so limited in scope as to be ineffective, than neither viruses nor application bugs in the client software matter.

Windows: Could handle this problem by creating a single new account called “client_apps” or the like. This account would have its ability to bypass traverse checking disabled in the security policy. This account would only have the minimal rights over each client application’s user space. Cache files and such would be moved in the user templates to be lateral to each other, and disable directory traversal would be enabled on the root of each application’s paths. Other specific rights over objects like printers could be enabled as well. This prevents different users using the same client_app account from violating privacy and prevents different applications by the same user utilizing the same client_app account from transitioning data from one client to another surreptitiously. There is no increase in overhead aside from the addition of a single user for any sized/complexity system.

My Understanding: My understanding is that Linux has effectively no capacity for this at all. You could create a new account for every single user for each client client_bob_email, client_bob_web, client_jack_email, etc and give each appropriate rights… but with a moderately sized system of 2000 users and only five applications, you now have an extra 10,000 accounts to manage. Another approach would be to use a single account, and jail every single client application process, but then you have trouble with the normal user interacting across the jails, plus the increased overhead and complexity of having thousands of jails running.

---

The answer I received over and over was "SE Linux"

Considering my concerns with third party research projects just dumped into production systems with no further evaluation or modifications this clearly isn't a good answer.

At this point I must mark this down as Linux is incapable.

cheers,

catch

I'm a programmer, so I like to think anything's possible. On the other hand, I really haven't understood any of your questions. They seem to be things that people who do almost the same thing as you would be familiar with. I'm just a kid trying to get through college, so I'm not going to lose sleep over not understanding your questions.

Also, I think you should stick with the windows solutions you seem to already have. This sort of seems like an all or nothing thing, and so far in your opinion linux is lacking in 3 of 5 categories (probably 5 of 5, but we don't know yet). I would like to think linux is capable of anything, but time is probably a factor. So, if it doesn't happen to be something trivial to make it capable, I don't think it will work for you.

I think I should start learning more about windows. I'm lacking in that category. Then again, I don't know much about linux either. So much to learn, so little time. Sorry for wasting a post without an answer (I don't feel that bad, because that's all that's going to happen in this thread anyway :)). Peace.

Quote:

---

At this point I must mark this down as Linux is incapable.

---

You are an insufferable troll. Few people are impressed by your abundance of
bullshit jargon. You are not asking these questions in good faith, but looking to
impress or intimidate people. Why don't you reveal the real reason
for this exercise?
:cool:

catch,

First of all, you must realize that all of linux is based on third-party applications and developments. All have been evaluated to some degree, some more than others. Unfortunately at this point, there is no official line in the sand or standard where a third-party application is considered "evaluated". It's all a matter of perception and degree.

The difference between using an open source solution such as linux and a solution such is Windows is entirely a risk management solution. By paying more for a solution backed by a major international corportion, you are effectively migrating that risk, and the process of fixing holes and bugs, to them. By choosing a solution such as linux, you are also choosing to accept the responsibilty of using a system that does not have this backing. You can't have your cake and eat it too. The effective and secure use of linux relies on its users and administrators, where Windows relies on the developers.

That being said, it is entirely possible to limit the data in an application's sandbox in the manner you are asking. I have done just such an experiment.

Any services running that are accepting data from the Internet have been chrooted on a read-only partition. They cannot see anything beyond their jail, and cannot write to anything inside it. A seperate partition for data and logs is used, mounted without execute permissions, for data such as mysql databases and webserver logs. The log server, syslog, is also in a jail and running from the same read-only partition, writing its logs to a noexec partition.

In practical terms, this translates to having a /chroot directory which is a seperate partition on the hard drive. This partition is mounted read-only. Should any configuration changed need to be made, the service is taken offline, the partition is remounted with write permissions. the appropriate files are altered, the partition is mounted read-only again, and the service is restarted. Now since the sercvice would need to be taken offline in most cases, or at least restarted, for configuration changes to take effect, this is not a problem. Downtime issues are more an issue with redundancy that the methodology of this setup. /var is mounted with write permissions, but as noexec as well. Now, inside each jail, /var is remounted in a different place, such as /chroot/httpd/var, /chroot/snort/var, etc... In this manner, each service can read and execute only that data which it cannot change. No data can be written anywhere outside of /var, which cannot be executed. This solves both your dilemmas. No incoming data can be executed, nor can any application process (available to the Internet at large) read any data outside of its sandbox.

Of course, creating a new account for every user and every application would become prohibitve. Therefore, a different approach must be used, such as my theory of chrooting every service. I'm sure other solutions exist, but this is what I use. Chrooting every service has proven to be technically demanding to say the least, and not nearly as convenient as disabling account permissions in a Windows security policy. But it can be done, and without the need for SELinux. It is my opinion that this approach is more secure than the careful tweaking of directory traversal permissions as would be used in a Windows environment. The applications are kept unaware of the existence of the rest of the system. The security precautions are taken at the operating system and filesystem level, and not the account permissions level.

I fear you are looking for Windows solutions in a Linux world. To effectively use linux on a production basis, you must take an entirely different approach to the security of your systems. You cannot apply, technically, a Windows security model to a linux environment. It won't work. Where Windows uses a client application account, linux uses chroot jails. Both work as effectively as the other, limiting access to data and preventing arbitrary execution. It seems to me you have already made the decision of linux being incapable, or are at least biased in that regard, whether you realize it or not. In this question you have provided for us an answer before even awaiting our responses. That to me smells of bias.

Yes, Linux can do what you are asking, but not in the same way Windows does.

Are you serious RC? If so, I'm very disappointed in you. :(

We all wanted to know how lunix confronted basic, typical security needs. Plus how they were implemented./ In (2005)
:rolleyes:

Some of the best material on the front board in long time.......take a gander out there now 3 suicides.

Too much trippin’ and my soul’s worn thin.....I need a breath of trusted air.

Quote:

---

basic, typical security needs

---

Go. Re-read the question, and tell me, without laughing, that those
are basic security needs. He's trying to pull your chain for laughs.
:cool:

Without a doubt, I think you're playing dumb blond with us. Nobody's trying to dastardize anyone here, and for Christ sake, the "jargon" is common syntax...... and can be found in simple Microsoft documentation......good documentation at that. ;) If you have any trouble consult the RFCs, STDs , FYIs and BCPs archives - RFC2828 would be a good start.

Quote:

---

First of all, you must realize that all of linux is based on third-party applications and developments. All have been evaluated to some degree, some more than others. Unfortunately at this point, there is no official line in the sand or standard where a third-party application is considered "evaluated". It's all a matter of perception and degree.

---

This is entirely untrue... several useable package sets with typical configurations have been evaluated... have a look at the FERs for the various Linux ISO-15408 audits.

Quote:

---

The difference between using an open source solution such as linux and a solution such is Windows is entirely a risk management solution. By paying more for a solution backed by a major international corportion, you are effectively migrating that risk, and the process of fixing holes and bugs, to them. By choosing a solution such as linux, you are also choosing to accept the responsibilty of using a system that does not have this backing. You can't have your cake and eat it too. The effective and secure use of linux relies on its users and administrators, where Windows relies on the developers.

---

Again not true, several Linux vendors offer this developer backing.

Quote:

---

That being said, it is entirely possible to limit the data in an application's sandbox in the manner you are asking. I have done just such an experiment.

---

Are you sure?

Quote:

---

Any services running that are accepting data from the Internet have been chrooted on a read-only partition. They cannot see anything beyond their jail, and cannot write to anything inside it. A seperate partition for data and logs is used, mounted without execute permissions, for data such as mysql databases and webserver logs. The log server, syslog, is also in a jail and running from the same read-only partition, writing its logs to a noexec partition.

---

I am not talking about services... I am talking about desktop applications. Where there is a need to both read and write and potenitally execute but all of that must be contained in the confines of the sandbox.
Hence I said:
"What: How can I restrict any number of client applications on a large-scale system, so that incoming data cannot be executed nor can it read or written to beyond the application’s sandbox?"

Quote:

---

You cannot apply, technically, a Windows security model to a linux environment. It won't work.

---

And yet you can apply a Linux security model to a Windows system... according to http://portal.acm.org/citation.cfm?id=1030093 this would clearly indicate Linux as having a less expressive model... which in this case makes it incapable.

Quote:

---

In this question you have provided for us an answer before even awaiting our responses.

---

Actually I already received many, many answers... this is a carry over from another thread where I asked the questions via PM to prevent tainting the answer pool.

Quote:

---

Go. Re-read the question, and tell me, without laughing, that those are basic security needs.

---

They are very basic needs... I am trying to prevent users from spreading malware from untrusted sources while allowing the to propigate both data and executables from trusted sources without the hassel of requiring everything to be digitally signed. To make this even more complicated, some users frequently need to use different computers depending on which team they are with so this must be done on a roaming profile basis. Multiply this by the sheer number of users... and you have a real problem that needs a solid yet robust solution that must be immune against 0-day malware.

What do you prefer? The totally open let users install anything and hope the AV catches it? Or the nazi-like users can install nothing (which is great for development environments)

cheers,

catch

Edited to add:
I've attached the Tripunitara document for those of you lacking access to the ACM's Special Interest Group in Security Access and Control.

Indeed, I will have a look. My frst question of these evaluations would be whether or not Windows is subject to the same evalutaion. We would then have a standard from which to draw on. You are correct, though, that many companies offer prepackacged linux solutions. I missed the boat on that one. The difference would be, of course, that this support is no longer coming from the company that designed your operating system (or distribution), unless you buy support directly from Red Hat or Novell (maybe others, but you get the idea...)

Quote:

---

Are you sure?

---

Yes. I am. But you did ask if I would be able to apply this method to ANY desktop application, and not just publicly available service. That would be possible too. Suppose I chrooted openoffice, for example, providing only those libraries it needs to run in a jail. I could then access user data in /home/[user], which is hopefully mounted noexec. The partition soffice resides could be mounted read-only as well. But truth be told, I have never done that. It would be an interesting experiment. Now, if I am able to chroot desktop application processes such as openoffice, mozilla, firefox, the gimp, etc.etc.etc..., would you agree that it is technically possible to place each application in a sandbox?

I agree that this would be very technically demanding and time confusing, but it should meet your requirements, in that so application process would be able to read data outside of its sandbox, nor would it be able to execute any data it recieves. If I can get this done with openoffice (and I believe I can), will you agree that it can be done with all applications?

And I doubt you can apply all linux security models to Windows. I have not seen any capacity in Windows to create a jail for its application services, unless I'm totally in the dark on that one. It is, I feel, one of the best security measures that linux provides.

But now I must sleep... I look forward to your response.

Striek... you mention jail...

Quote:

---

Another approach would be to use a single account, and jail every single client application process, but then you have trouble with the normal user interacting across the jails, plus the increased overhead and complexity of having thousands of jails running.

---

So... under your system I have openoffice jailed... how do I share documents that I've created? And that is just the first of many concerns I have.

Quote:

---

And I doubt you can apply all linux security models to Windows.

---

Yup... every aspect of it's access control model can be replicated and then some.

Quote:

---

I have not seen any capacity in Windows to create a jail for its application services,

---

Select the application/service is question and disable directory traversal under security properties.

Quote:

---

It is, I feel, one of the best security measures that linux provides.

---

Actually jail is just a less secure, lower overhead emulator as for as sandboxes go. Jail is frequently refered to as a secure subsystem... but this is simply not true and wikipedia is dead wrong here. Jailed subjects still use system resources with the same level of access as any other aubject... you merely have a wrapper.

cheers,

catch