Needs of network for MAC
August 25th, 2007 By shazkhan

After the comparison of trendy MAC enhancements, I have been figuring out the general needs of a network for MAC. We have three places where MAC can and is enforced:

  1. In Application: Where flow control of application is controled by labeling the data of the application. Current research is limited to MLS becuase its simple. And because the security type languages are not mature enough to handle the granularity. I have seen two framworks at this level, which make use of these languages. One of them has been partially integerated with selinux by using the application layer API to selinuxfs. I am curious why they are so interested in JAVA! There is no C extension.
  2. On Application Layer: This is achieved for applications that do not use TCP/IP directly. They use RPCs so the common network controls cannot handle properly. The reason is that port to application mapping is done by portmapper daemon. Thus the rpc headers carry the security contexts. Such applications are NFS and NIS.
  3. At TCP/IP Layer: Here the ports are labeled for the associated applications on both sides. I a hostile environment this would not prove useful so encryption would also be required. This is achieved by IPSEC associations being labeled. I am not fully satisfied by the mechanisms at this level because at one extreme we have lack of security and on the other hand manageability issues.

LDAP is on the todo list but nothing is currently being done about it upto my knowledge. The todo list also wants more granularity and API at TCP/IP layer.

Policy distribution being a great issue has no solid solutions yet. The only possibility to till now is a tranlation server, which would provide an equivalence mehanism for internode security contexts. But this is has been left as an idea and no progress is being made. IPSEC associations were provided only for subjects but currently they are working for providing object support but the work is hidden yet. They are thinking for CIFS support as well. Ephimeral ports can be handled with standard SELinux API for applications.

The biggest problem with distributed policy is the type enforcement, which is part of the security model/context. Leaving it out would be a solution but will affect greatly because code bindings will be lost, which will result in loss of integrity control. The context has three main models. User identity, role and TE. If one is lost it will affect the others because they are tied together to help each other. I am figuring out how much affect will be made. At the same time integrity can be measured with IMA and alike. I would like comments on what you ppl think about the differences in the integrity model of TE and IMA.

If anyone can come up with other ideas of network needs plz brainstorm so I figure out the requirements. There are others which I have’nt mentioned because they are trusted applications by SELinux. I find a gap over here because trusting applications is not a good idea. Information flows can work here. More on this when I get a solid insight on them.

What do you guys think should be my next target. Amin is sorting out to integerate his study with all this. So give ideas of possibilities. Any of you who thinks their work can have relevance plz share your findings so that we can be more useful to each other.

14 Responses to " Needs of network for MAC "
 
shazkhan
August 25th, 2007

I can make a good research paper out of this ;-) but alsa I have no job so have to work on thesis and forget papers for a while.

 
recluze
August 26th, 2007

Tell me one thing Shaz. I get the impression from the first few paragraphs that you’re also studying the concept of security at a high (application) level. Is that so? If yes, do you know anything about usage rights management. I’m not sure this is your domain or even if you should pursue this but I get the impression that that’s something you should at least know about if you’re going to move to application level security.

 
shazkhan
August 26th, 2007

Well dont know anything theorectical about it but just what it sounds like “managing users’ rights for resources”.
You know i was born smart and plus experiance has made me enlightened ;-)

 
recluze
August 27th, 2007

Yes. Sort of like that. It is the study and development of of time/user/usage/resource constrained policy framework(s). An application on usage-rights framework can decide whether to allow a specific user to open a specific file for a certain number of time at a given time/place. It’s quite complex but it’s sort of what concerned with what you’re saying here about application level security policies.

I’ve also seen your mail regarding SELinux problems/possible research areas. It looks quite convincing as a preliminary work but tell me one thing: What sort of work do you think is needed at a practical level to produce some results. I’m talking about programming. If you can think of some targeted work in programming and can give a crasher to get a guy started, I think I may have a guy who’s good enough to assist you from that angle. You know, to do the grunt work.

 
shazkhan
August 27th, 2007

I have been communicating with Amin and he is taking interest in integrity measurements. I am not getting your perception of application level security. But if you have a guy who can seriously handle this kind of complexity we can work on that angle. This selinux thingy is the future but is highly complex both in policy and extension. One needs to know the whole system. If he has both the qualities of technical and can cling onto the conceptual details that I provide him then we have another soldier which I would welcome open heartedly. And we need to discuss things. I feel very lonely with my haunted mind and whiteboard!

 
shazkhan
August 27th, 2007

Let me take another look at the todo list. I also had interest in LDAP extension but LDAP is again deviation which I cannot afford at this time. But another soldier can get onto that.

 
recluze
August 27th, 2007

First: about the loneliness and working alone. I can meet with you and discuss matters at hand on Sundays. if you want, we can voice chat on Monday to Friday from 3-4. You know, to discuss ideas, bitch about the problems… that sort of stuff.

Secondly, about the “soldier”, I’m not sure how much dedication I can get from him. First you have to show me some small project — something targeted — like, say, “change this scheduler code to this other scheduler algorithm”. You show me where, what thing needs to change to what other thing and I get it done. Tell me if something like this is possible.

We can only hope to find new talent through such targeted probing. I don’t think we can expect someone to come along saying, “i’ve worked on linux kernel programming”. We’ll have to induce them in the workflow while still keeping them safe from the academics and market of Peshawar.

That’s the primary reason I think we should all work in a single institution. We can at least handle the academics part. Right now, a student can’t possibly work on such projects for fear of getting an F in the final project.

 
shazkhan
August 27th, 2007

Ok I get it. But I also want to understand ur perseption of application layer security because I am not gettin it. About ur soldier lets see what I can get but personally i would like to do the grunt work because thats how we learn. Once we learn then we call it grunt!

 
recluze
August 28th, 2007

My perception of application level security is the collection of those aspects of security which are enforced by application softwares. Stuff like media players, PDF readers, browsers. I don’t think this is technically correct but that’s what I meant when I talked about it earlier. See point # 2 at the top of your post. Applications working at that level may use something like usage control. I was just wondering if you know about it. You can probably use the concepts of usage rights management. I’m not sure how though.

 
shazkhan
August 28th, 2007

Usage control w.r.t. MAC will not only lie on point number #2 but all of the three. The decision will be made at the kernel in the standard implementation while a userspace decision making module is also possible. Enforced by the the kernel and/or the application depending on the targeted needs. An application like web application will do most of it in the application while an application like emacs will use the kernel. There are many issues and gray areas when it comes to possibilities but the standard approach is that every thing is done by the kernel and very little by application layer.

 
recluze
August 28th, 2007

Usage control (or applications implementing it) is concerned with, for example, how many times you’ve opened the file. If it’s more than, say, 5, you cannot access it again. Is this a decision that can be made by the kernel?

 
shazkhan
August 28th, 2007

no but such constraints are not what selinux aims at. It is for integrity and confedentiallity. Timing constraints and how many times a file can be accessed is something which the application should do although such a policy can be implemented in selinux at kernel level but it would not seem right.
If you want this for a specific application then it should be in the application itself or a supportive module but if u want it to be system wide then selinux can do it, or a userspace security server anchored by selinux.

 
shazkhan
August 28th, 2007

This kind of policy can be best implemented on RSBAC, another kernel enhacement. Refer to my paper. It can use multiple policy models easily. But selinux was designed for userid:role:type model. Although it can support another policy model it would be very tedious.
Why don’t you check rsbac website they might already have usage control because almost all research policies are implemented on it!

 
recluze
August 29th, 2007

Yes, I understand now. Actually, I’m not really interested in implementing this thing as it is. I was just wondering if _you’re_ working with this. It could’ve been closer to security protocols and such. Anyway, this can be a nice line of research for anyone willing to pursue it.

Leave a Reply


(Required)

(Required)