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

I think these Linux questions are very misunderstood... initially I supected and in fact hoped that I would have been wrong in my assumptions. I have not followed the Linux development too closely in recent years because I saw no reason.

The original idea was to write a paper about "Why I think Linux dosn't meet my needs" and have it be focused more on the difficulties of viable information in the land of open source.

I was genuinely looking for some people to say: "Yes, Linux can do that like this blah." and then I would have replied "Wow, that exactly meets my requirements, excellent answer." And then I would have been off to research from the answer back to my initial understanding to determine why those gaps in knowledge existed in the hopes of finding a more reliable route to viable information.

Unfortunately I seem to mostly get answers that don't address my question, yet get positive APs because people think I am trying to bash Linux and feel some burning need to defend arguments for the underdog regardless of how irrelevant or inept they may be.

cheers,

catch

Quote:

---

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.

---

Ok, rather than OpenOffice, I have chrooted pico. This chrooted instance of pico cannot see, and therefore, cannot read, any data beyond its jail. Also, it has read/write access to the user home directories, which reside on a separate partition. This partition has been moutned at /chroot/pico/home with the noexec flag set. The /chroot partition on which the pico instance resides is set as read-only. So, it cannot write to its own jail -- only to the home directories of the users accessing it. Any data written by this instance of pico cannot be executed. I believe this solves both of your main questions... it also solves the problem of sharing documents you have created. Any user can write documents to his or her home directory with this jailed instance of pico, and after the fact, can share those documents as they normally would.

If pico was used as an avenue of attack, the kernel would prevent any data from being written to the jail. The only place the kernel would allow data to be written would be in users' home directories, at which point it cannot be executed -- even with root permissions. Since the libraries containing the system calls necessary to remount this partition with execute permissions do not exist within the jail, one would find it very difficult to execute code by the remounting of the partition, which is the only way I can see execute permissions being granted. Pico was used for simplicity's sake; I have no doubt that if I can manage this with pico, that I can also manage it with OpenOffice, or for that matter any application which I may wish to jail in this manner.

Quote:

---

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.

---

Granted. But I cannot see how this is in any way less secure than the method you suggest using Windows. As far as I can tell, the creation of a chroot jail and the denial of directory traversal permissions basically create the same environment then.

I use this method currently to allow my webserver access to user home directories, where they keep public html files. A chrooted shell server is also running in a seperate jail, with access to the same public html directories that the webserver has.

ALSO... the user database being used is currently a mysql database, which is also jailed. This as well solves one of your earlier questions of finding a centralized way to manage users. I believe it was your first linux question that this problem came up in, although it does not solve every question asked in that post.

If you want to have a look at my setup, PM me and I will provide you with access to my server. Tell me if my methods meet your requirements for this question.

Quote:

---

If pico was used as an avenue of attack, the kernel would prevent any data from being written to the jail. The only place the kernel would allow data to be written would be in users' home directories, at which point it cannot be executed -- even with root permissions.

---

Unfortunately this creates a few new problems... who owns the files created by this process.. root? What if users need to alter the permissions?

What if users need to be able to develop and execute other applications? (I did say it was a development environment)

What if the offending malware is a script rather than a executable?

Which if users may need to acquire new executables to extend (in your example) pico, but they must be confined to the same sand box?

All of these are very real questions (the last most obvious with web based shipping/receiving applications where an exe is downloaded to support advanced functionality like the handling of technical drawings, CAD, etc)

Quote:

---

Granted. But I cannot see how this is in any way less secure than the method you suggest using Windows.

---

I have never said it was less secure than Windows, I said it is less functional... and changes to make it equally functional will reduce the security.

Quote:

---

I use this method currently to allow my webserver access to user home directories, where they keep public html files. A chrooted shell server is also running in a seperate jail, with access to the same public html directories that the webserver has.

---

You keep going back to server environments... and yes I agree that for those environments they are fine since each user only deals with one jail... but when you have a single desktop accessing half a dozen jails... this gets insanely complicated and the lack of lateral sharing makes the issue even worse. Add thin clients and users changing workstations and again you suddenly need to manage the sharing of thousands of jailed environments.

If client applications need the ability to write and execue data... clearly you can't have multiple instances of the same process, even if not at the same time share the same jail or you introduce new privacy risks if nothing else.

See what I'm saying?

cheers,

catch

Quote:

---

who owns the files created by this process.. root?

---

The files created by this process are owned by the user running them. After the chroot() call is made, the user ID is changed to the user requesting the process, and runs as it normally would run... with the permissions of the user running it.

Quote:

---

What if users need to be able to develop and execute other applications?

---

If we are to allow users to develop and execute applciation, what is to prevent a threat agent from using that users' credentials to execute other code? In my solution, any application process that a user requests would be jailed, and only able to run code within that jail, if we provide the necessary permissions to do so. These applications would be run as normal, with the permissions of the user running them, provided they are not setuid root. But, since any application would need to access data from a shared resource where users would store this data, that shared resource (i.e. disk space with execute permissions) could become an attack vector with which to attack other applications. One solution might be to limit code execution permissions to the owner of each file, and deny those permissions to everyone else. While this would not prevent shared disk space from becoming an attack vector, it would slow the process down. But still, any threat agent with the credentials of that file's owner might execute it. You may have a development environment that uses this shared resource for code execution. A web browser might also use the same disk space. Any file placed on that resource by the web browser might then be read and executed by the development software with the proper credentials. But I cannot see how your solution would prevent this. In essence, if we are to provide code execution permissions at all, we must accept the risk that that code may be malicious. In your solution, user data would also be stored on a shared resource, and be readable by many different client applications, all of which may read and execute that code.

Quote:

---

Which if users may need to acquire new executables to extend (in your example) pico, but they must be confined to the same sand box?

---

Again, if we are to allow suers the permissions to install plugins and extensions, we must also accept the risk that those plugins and/or extensions may be malicious. Steps can be taken to limit damage and slow progress, but I doubt any security policy can entirely prevent either.

Quote:

---

What if the offending malware is a script rather than a executable?

---

Now we open a whole new bag of beans. A script can be read, and executed, from any application with the appropriate programming, so long as the application executing it has sufficient permissions. But the same could be true of any executable code, whether a script or in binary form. A virtual machine may load a binary file from any place on a filesystem it may be allowed to read it, and execute it from somewhere else. The problem is that the actual code being executed does not reside on a portion of the filesystem where we have denied execute permissions. With your solution, what is to prevent a virtual machine from reading binary code from a non-executable file, and then executing that code from somewhere else?

Quote:

---

If client applications need the ability to write and execue data... clearly you can't have multiple instances of the same process

---

Your original question was to find a method to prevent the execution of incoming data. If client application can write and execute data, then we cannot prevent the execution of incoming data, unless I'm way off the mark on that one.

I agree that creating jails for each application process would be very complicated. But you would hardly need a new jail for every process. You would, however, require a new process for each user acessing that application. But I disagree that that would make things overly complicated. Now when you speak of a lack of lateral sharing... my solution is specifically designed to prohibit lateral sharing, as this becomes, as I said eariler in this post, an attack vector by which malicious code can spread from one application to another, and has privacy concerns as well. Where lateral sharing is required, I have allowed applications to read data from a shared resource, yet still limit the damage done by said application, should that shared data prove to be malicious, to a single sandbox at a time.

I think the same problems you give to me in a linux based environment would also apply to a Windows environment, although the solutions may be different. If any code can be executed, malicious code can be executed. If lateral sharing is allowed, privacy risks are introduced. How would you plan to solve these problems in a Windows environment? Specifically, how would you allow users the ability to generate and execute code, extend application functionality with executable code, yet deny the same execution to malicious code? How would you allow lateral sharing, yet avoid associated privacy risks?

Ok your solution is going in circles... and you haven't introduced any new information over my original post.

Quote:

---

The files created by this process are owned by the user running them. After the chroot() call is made, the user ID is changed to the user requesting the process, and runs as it normally would run... with the permissions of the user running it.

---

Then how are these files any different? The jailed process creates files outside of the jailed environment (why have the jail?) that fall under the original users credentials. This seems like it meets the requirements to you?

Quote:

---

If we are to allow users to develop and execute applciation, what is to prevent a threat agent from using that users' credentials to execute other code?

---

In my solution, the threat agents lack the access... in yours, nothing.

Quote:

---

In my solution, any application process that a user requests would be jailed, and only able to run code within that jail, if we provide the necessary permissions to do so.

---

Yet according to your point above these jailed environments can create object outside of their jailed environments... object that lose the jailed credentials and acquire the user's credentials.

Quote:

---

In your solution, user data would also be stored on a shared resource, and be readable by many different client applications, all of which may read and execute that code.

---

Not true at all... see in my solution I can provide process credentials and user credentials at the same time... yours does not. Not only that my credentials are more expressive allowing again for greater granularity.
The only way for you around this is to create a seperate jail for every application used by every user (so userX, userX_firefox, userX_clientapp, etc) otherwise if you have jail_firefox as an account all that data is availible to every user that uses that jail.

Quote:

---

With your solution, what is to prevent a virtual machine from reading binary code from a non-executable file, and then executing that code from somewhere else?

---

How will the code get somewhere else? Yours requires moving objects around, mine does not.

Quote:

---

Your original question was to find a method to prevent the execution of incoming data.

---

No it wasn't... this is the second time you have clearly misread my original question.
"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?"
"executed... read or written "
"beyond the application's sandbox "

I think if you take the time to review my question fully you will see that I addressed and dismissed your solution because it doesn't work. It doesn't matter if you use a jail, an emulator or any other subsystem... they all result in the same problems.

Quote:

---

Now when you speak of a lack of lateral sharing... my solution is specifically designed to prohibit lateral sharing, as this becomes, as I said eariler in this post, an attack vector by which malicious code can spread from one application to another, and has privacy concerns as well.

---

Lateral sharing isn't an issue as objects move across they will inhierit new rights and privacy isn't an issue since they are only laterally shared across a single user.

Quote:

---

If any code can be executed, malicious code can be executed.

---

Hence the wish to sandbox it.

Quote:

---

Specifically, how would you allow users the ability to generate and execute code, extend application functionality with executable code, yet deny the same execution to malicious code? How would you allow lateral sharing, yet avoid associated privacy risks?

---

Who said anything about denying malicious code? I merely wish to keep code that originated from the sandbox to remain in the sandbox and code that originated outside the sandbox to be useable nearly anywhere (the specifics of where and those security concerns are beyond the scope of this conversation... so nearly anywhere will have to do).
Privacy issues do no occur because users still own the processes and are still bound their their access controls... additionally they are bound to the process' restrainsts. Since everything occurs under the same uid... no privacy issues are introduced.

cheers,

catch

Quote:

---

Originally Posted by catch

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.

---

Really? I'm extremely interested in how that works; could you please explain this? It's way too relevant to my current job for me to leave this dormant.. This is knowledge that I need.

I agree with rcgreen and striek as far as the belief that your problems are Windows problems and that you are addressing them in a Windows way (but, after all, you're not disagreeing with this, are you? You offered us solutions for your problems in Windows together with the questions).

If all code remains in the sandbox, how do you share the code, anyway? Do you give multiple users access to the sandbox? Where's your security then?
You do realize that if you share your work, then people can steal it, right? Catch, you're being unfair because you always bring out one more layer where the system can be abused, and I would like to throw social engineering in your face, but your clever answer would probably be something along the lines of "Oh, but we're only talking about the system's security!".. And I hope it isn't, because the users are part of the system's security. So where's your security if we talk about social engineering? What exactly in all of your questions is helpful in strengthening the weakest link... The users?

Well I created a method for jailed process to create objects outside their jail to allow those objects to be shaed with other applications and/or users. If a process can only create objects within its own jail, then how are we to share those documents without the use of a higher level process, outside of that jail? In your solution, mustn't there be some process that can read those objects from outside the jail so they may be used in other sandboxed appilcations?

You wish to create a sandbox right? Am I not doing the same thing with a jail?

But perhaps you're right, I may not fully understand the question. So... let's say we have a small system with three applications - a CAD application, to which we wish to give users the ability to extend functionality with their own executable code brought in from third parties, an IDE with which they need to be able to develop and execute their own code, and a web browser, which may also need to be extended with plugins. All three of these application must be able to see and use the data created by the others, and store that data on a remote fileserver. We then have five users (let's call the Alpha, Beta, Gamma, Epsilon, and Omega) who need to use all three of these applications each. There are currently no access controls such as we have discussed in this thread.

Provide me with a sloution that meets your requirements in a Windows environment, and I will attempt to provide a similar solution for a linux environment. I still say it can be done, although not as easily as in a Windows environment.

I don't know if this is pertinent but it sounds like it could be employed.. whenever Singularity becomes available...

http://research.microsoft.com/os/singularity/

The part about SIPs.

Some comments on http://www.darksideprogramming.net/2...syst.html#more

[It was on Slashdot and I hate starting threads that simply copy those news :)] But after a quick read it seemed that it could apply.

Simplified Question:
The problem is the very real issue of malware being surreptitiously delivered via client software.

Functional Requirements:
- Processes must not be able to process objects beyond their respective sandboxes.
- Processes must be able to read, write, and execute objects within their sandboxes.
- Users must be able to seamlessly move objects in and out of the sandboxes.
- User must be able to read, write, and execute objects within their environment.
- Normal user permissions must not be extended via proxy agents or in any other manner.

Striek, if you don't understand how your solution fails to meet these requirements, perhaps you are not the best person to be answering this question.

Quote:

---

Really? I'm extremely interested in how that works; could you please explain this?

---

Linux uses an RWX scheme based on UID, GID, and everyone. This scheme is used for anything that can have permissions.
Windows on the other hand allows you to set many more permissions (traverse folder, read attributes, change permissions, take ownership, read permissions, write attributes, delete, delete subfolder, etc) and thee permission may be set to allow or deny (which is very useful in preventing rights from propagating via shared subjects). Windows allows these permissions to be set by UID, GID, and everyone... as well as by device or system. Additionally while Linux only provides for one UID (the owner), one GID, and everyone... windows allows as many UIDs and GIDs as you wish... the owner doesn't even need to be one of them.
In addition to all of that, the security policy editor allows you to further define rights such as: backup files, change system time, bypass traverse checking, create global objects, replace process level tokens, restore files, take ownership, create permanent shared objects, etc. Again these can be defined to many individual users and or groups.

Understanding this, it is clear to see that every expression of Linux's permission bits is contained within the expressiveness of Window's ACLs.

Quote:

---

If all code remains in the sandbox, how do you share the code, anyway? Do you give multiple users access to the sandbox? Where's your security then?

---

By assigning different security models to the sandboxed processes and the user using those process. The security for the user is the same as if no sandbox existed.

Quote:

---

You do realize that if you share your work, then people can steal it, right? Catch, you're being unfair because you always bring out one more layer where the system can be abused

---

People stealing the work isn't much of a concern... my concern is users only share that which they intend to share... not sharing things they are unaware of.
Everything I've said has been at least implied by the original post if not outright declared.

Quote:

---

And I hope it isn't, because the users are part of the system's security. So where's your security if we talk about social engineering? What exactly in all of your questions is helpful in strengthening the weakest link... The users?

---

The social engineering risk is largely decreased by the client application's in ability to surreptitiously execute malware in a harmful manner. Additional steps are required on the user's part that would fall beyond their typical manner of operating, which would make automated social engineering very difficult. As a point beyond the scope of this question... each user environment is sandboxed from the system itself as well with regard to the scope of executables and the limitations of where data can be written to and read from. So even socially engineered or intentional malware will be confined to a single user account... without some serious inside effort. (which should all be auditable)

cheers,

catch

Quote:

---

Processes must be able to read, write, and execute objects within their sandboxes.

---

Catch,
I understand where you are going with this but I need for you to clarify something. There is no permission called just "traverse directory" It is "traverse directory/execute file."

It's not a permission that I use a lot because in my environment I don't have terminal servers, or machines where clients have active logins and their own directories. But from the MS help it would appear that this setting stops directory traversal and executing files. So are you setting this permission on the applications or on the directories? Am I mistaken that if you put it on a directory you would not be able to run anything in that directory, or move out of that directory? How does this still allow a user to execute code?

if you set this on the root of each client application-

Quote:

---

and disable directory traversal would be enabled on the root of each application’s paths.

---

For which users?

How do you run the applications? Your explanation does not really explain the actual configuration and how the client_app accounts ties into the what the user is doing. For whom do you disable the right to traverse directories and execute files? Do you disable it for all users? That is what I think is missing from your explanation.

Wouldn't you need to setup the application to always run as the client_app account? If you only deny the directory traversal/execute file permissions for the client_app account, and the user program is started in the context of the user, doesn't it still have that permission?

I did some searching and I can't find any resources that detail this configuration method. The best I can come up with is this MS research article that talks about using restricted SIDs to prevent malware from being a problem. It doesn't detail how to actually do it though. Most notably is this reference from page 32- "Restricted contexts can
implement simple security policies, such as disabling administrative rights and privileges
for most programs, as well as more restrictive policies such as limiting a program to
accessing only a single file."

http://www.cs.washington.edu/homes/m...ers/tissec.pdf

This definitely does what you are talking about, but it would appear in a much different fashion. Or is the secondary user account how you configure the restricted SID? Meaning is the restricted SID the client_app account?

Mo... you do raise interesting points, however I would like to firts come to a conclusion with this question before going off on Windows' security. I will say that a combonation of the second SID, traverse directory (/execute which I figured would only complicate this thread by including) setting, and the "start in" setting are what makes this work.

I do have a tutorial started on Windows client sandboxes started... and I am quite familiar with that document (I believe I may have even referenced the ACM copy here in the past). I think this would be a good area of conversation, I just want to keep on point here as this about about a requirement and how Linux meets it.

cheers,

catch

Sorry, wasn't trying to confuse the issue any..


If you have any other references on performing sandboxing as you describe on a windows system I would be interested in reading more about it. It definitely seems like the right way to go to secure multi-user systems. I also see how this could be useful for doing certain types of testing on unknown code.

Would this be anywhere close to what you need? I haven't tried it but I'm pretty sure it's possible.

What if you chrooted all your applications in the same jail, and made one group which all of them run with the GID of. All the directories which it writes to and executes from would be owned by this group, and the user owning the apps wouldn't matter I don't think. You could make it a user with no perms anywhere (but the group would have perms). So all the files it needs to execute are owned by the dummy user, and the group of the chrooted apps and have perms r-x for the group. Same goes for writing, directories it needs to write to will be rwx for the group and anything else shouldn't need any permissions. The user could run all the apps with an alias like

/usr/sbin/chroot /chroot/client_apps/ /usr/bin/app

and the alias would be called app. The application would be running in the jail with UID of the user who started it, and GID of the chrooted apps (not sure if you would need to use a setgid bit in the perms here or not). All users would have a folder for their documents in the chroot owned by their UID with all perms, and no other perms, or possibly all users are in a group, and maybe you can have it owned by that group and give the group whatever permissions you require. Since the apps would run as the user, they could write to the user's directory in the jail. You could set a umask of 077 for each user so that new files created by them will have rwx------ permissions.

I'm guessing this is nowhere close to what you're wanting but I thought I'd throw it out there anyway just in case.

I also had a question. I was looking for what you were talking about to disable directory traversal and I couldn't find it. Where am I supposed to select the application to get to the security options?

h3r3tic... I am having a little trouble following that... would you mind diagraming it for two users and two apps? (doesn't need to be any fancy formatted diagram)... just indicate the subjects and objects and who can access what in what way. Paint would work fine.

Traverse folder/Execute File is:

right click the objects > security tab > advanced button > view/edit

It is the first option... however you need to do a little more than just setting that option or else the application won't work. You need to alter the security policy and use "start in" shortcuts. I wasn't able to find a tutorial on the subject, so keep an eye out for mine... in the mean time read the doc that mo linked, it is very informative on the subject of Windows security.

cheers,

catch

I started doing this in indesign because I was going to make a diagram like you asked, but I ended up just typing a bunch of stuff trying to explain what I posted about. Hopefully I made it clear, but I probably didn't. I didn't get to the two user, two app situation till near the end of the pdf ;). Like I said at the end, it's probably not what you need and I expect you to say so and why. Flames are welcome :).

Quote:

---

So even socially engineered or intentional malware will be confined to a single user account... without some serious inside effort. (which should all be auditable)

---

That's... Kinda the default behavior in GNU/Linux as far as I can tell...

h3r3tic... this solution seems a good one on the surface... but I think it will run into problems with large numbers of dissimilar users sharing systems.

In our specific system we have modular shipping & receiving clients, modular distributed software control management clients, and various other modular tools (pay roll, HR, Ops sheets, etc). The idea being that we can use the operating system's access controls to segregate the tools available to each user rather than having each application control access. This allows the development of simple templates and centralized control over everything, while easing the security requirements of internally developed software... thus speeding the process.

However, in such an environment where access was controlled by a single GID I think you will run into some serious complexity issues. (as I stated in my initial example). If the Linux access control model had "Deny" functionality that would provide a very dirty fix, but even then it would need to be both granular to a single user while extended across many users... or groups.

I have no doubt that what I want CAN be done in Linux, I just don't see how to do it without creating a huge, untenable mess.

cheers,

catch

h3r3tic,

The only problem I see with yor solution is that a user cannot make a chroot() call, since that call requires root permissions. That was a problem with my solution as well. Since users must use root permissions to make the chroot() call, the are extending their privileges with a proxy application.

catch,
I fully agree with you... it would be a configuration nightmare to set up a solution for this problem with Linux. I don't think it would be as complex as you think it would be, but it would nonetheless be signifigantly more complex than a Windows solution.

Now, what if one were to write a utility that could manage these jails ans accounts? Are you more woried about the actuall process of configuring the solution, or is it the security problems which may pop up if such a solution is improperly configured? I'm sure it would be quite possible to write software that could manage a solution that would make this work in a Linux environment...

Quote:

---

Originally posted here by Striek
h3r3tic,

The only problem I see with yor solution is that a user cannot make a chroot() call, since that call requires root permissions. That was a problem with my solution as well. Since users must use root permissions to make the chroot() call, the are extending their privileges with a proxy application.

---

Yeah, I thought about that too after I posted. I was thinking about sudo, but that still runs chroot with root privileges right? What if you made the executable setgid? I guess it doesn't matter anyway, it's a nightmare solution :P.

Which increases its complexity, thus lowering assurances right?

Quote:

---

Yeah, I thought about that too after I posted. I was thinking about sudo, but that still runs chroot with root privileges right? What if you made the executable setgid? I guess it doesn't matter anyway, it's a nightmare solution :P.

---

Ah yes !mitationRust . Gruesome isn't he? Fumbles at your head like a freshman pulling at a panty girdle.

Yup.

Fourth Linux question? I'm kinda curious to know what else is going on in here.. :)