Third Linux Question

[catch]

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

[mohaughn]

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.

[skiddieleet]

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?

[catch]

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

[skiddieleet]

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 .

[Trevoke]

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...

[catch]

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

[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.

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...

[skiddieleet]

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.

[!mitationRust]

Which increases its complexity, thus lowering assurances right?