Multilevel security (MLS) presents a set of users and a set of objects to be accessed. Both the users and objects are classified hierarchically with a security level as well as need-to-know categories. For example, you may have an “Unclassified” user trying to read a “Classified” object or a “Classified Crypto” user trying to write a “Classified Nuclear” object.

The Bell-La Padula model defines a way for deciding whether to grant access in each of these cases. This model uses a formula to define whether a certain level combined with a category dominatessome other level combined with a category. We’ll define “Classified” as a higher level than “Unclassified”, so in the first example “Classified” (with no category) dominates “Unclassified” (with no category). I’ll ignore categories here for simplification, but in reality for one classification to dominate another, both its level and category set must dominate the other.

Having this domination function defined, we can describe the two main properties in the Bell-La Padula model:

• The Simple Security Property – A user can only read an object if the classification of the user dominates that of the object. (Also known as “read down” or “no read up”.)
• The *-Property – A user can only write to an object if the classification of the object dominates that of the user. (Also known as “write up” or “no write down”.)

The reasoning behind the Simple Security Property is pretty straight-forward. If you’re concerned about confidentiality, you definitely don’t want people to read anything that they don’t have to. It’s the second property that raises some eyebrows. Why should a user be able to overwrite something that they can’t even read? Doesn’t this create huge issues with integrity?

The answer is simply that BLP doesn’t concern itself with integrity. But when you look at the property solely from the concept of confidentiality, the idea becomes a bit more clear. A user at a certain level knows information that users at lower levels don’t, so he shouldn’t be able to write anything to those other levels. However, users at a higher level already know that information so in that sense it’s okay to write to a higher level. You don’t have to worry that someone will see something they shouldn’t know about.

Another question in this model is how can someone give an order to their subordinate at a lower level? Here BLP adds the concept of trusted users. These are a special type of users who are proven trustworthy and who have the ability to write to lower levels. To me this seems like a cheap way of adding in functionality that should be provided by the basic system. “How do you make sure someone is trustworthy?” seems like as much of a complex question as “how do you make sure information isn’t written where it shouldn’t be?” Perhaps the reason for considering the first is that it’s easier to just have a person decide the second.

Overall, it’s interesting to find that the Bell-La Padula model has retained such influence despite its inherent shortcomings. As we continue in my Computer Security course, I look forward to seeing how more modern models compare and how they’ve solved the integrity problem.

CS 336: Analysis of Algorithms (Myers)

This class focuses on formal proofs of algorithm correctness, including topics such as weakest preconditions, developing invariants, induction, and probability. Even for a computer science course, it’s very math-intensive. One of my favorite things about this class, though, was having a support group available. There are some classes where you’re supposed to figure out everything on your own and not discuss the homeworks at all, while here we were encouraged to attend ACM’s weekly theory reviews or our own groups to meet up and work on the homeworks. For a class where the students have such varying backgrounds (everyone teaches 313k differently), it’s really necessary. I may not have been able to get a firm grip on recurrence relations without it.

CS 352: Computer Systems Architectures (McKinley)

This was McKinley’s first time teaching CS 352, and unfortunately it was at times very obvious. Reading the textbook was helpful, but the exercises often used terminology not in the rest of the book and were very confusing. The midterms were also insanely difficult. I’d go in thinking I had a good understanding of the material but then leave completely stunned. (Being able to keep the graded midterms would have been nice.) But for the final at least, I had almost a whole week to study. I read the book, worked out extra exercises, summarized the class notes, checked Wikipedia for clarifications, and everything came together. Sure, there were a couple of small things that I couldn’t remember ever going over, but in an hour and a half I was done and ended up with a 90.5–the highest grade on the final for any student. If you want to do well in this class, you need to have a lot of time to devote to it.

CS 378: Software Design (Batory)

This has been probably my favorite computer science course. We learned how to reason about programs using UML and studied refactorings, design patterns, and architectural patterns. For even common design patterns like hooks, I had never understood before exactly what they were. My favorite part, though, was learning about parallel architectures and having the opportunity to simulate everything from a basic join up to the parallelized Gamma join architecture. It’s a difficult class, but Batory’s generally an entertaining lecturer and I would recommend it to any computer science student.

Anyhow, some closing thoughts on the classes that have encompassed me for the past few months:

CS 315: Algorithms and Data Structures (Novak)

Novak’s CS 315 site is one of the best in the department–if for nothing else than having an excellent vocabulary list and so many ways to browse the class notes. Novak wasn’t the most exciting lecturer, but he always made sure we understood what was going on. If I could change one thing about this class, though, I’d like to look at implementations a bit more. He’d tell us that the code already existed, and his focus was on making programming faster and easier for others, but for now I still want to see things very in depth.

CS 310: Computer Organization and Programming (Boral)

In this course, we got to learn the fundamentals. We implemented our own stack and heap using LC-3 and learned how to write machine code. There’s much to be learned from this, but I think the main thing is to cherish the high-level languages we get to use (I still think it’s funny to call C “high-level” though) and to optimize how we use them without having to constantly focus on the small details. Boral was usually an entertaining lecturer, and if it wasn’t for the unpredictability of his tests I’d love to take another course with him.

CS 313K: Logic, Sets, and Functions (Lifschitz)

I took this class ten years ago as Philosophy 313K, so I expected this to be mostly a refresher course, and as such much of it was quite boring. However, I couldn’t miss any lectures because the exams would have questions about topics that weren’t in any of our notes or assignments. The course was mainly focused on mathematical functions and sequences, and I was a bit disappointed that logical quantifiers and connectives weren’t really covered. At least it was a (mostly) easy A for me.

EE 316: Digital Logic Design (Touba)

Between readings, homeworks, and labs, EE 316 is probably the most time-intensive course I’ve taken so far. (The required lab section doesn’t count for any credit hours.) Much of the material looks easy in retrospect, but the pace is so quick that you’re sure to get behind at some point along the way and have a lot of trouble catching up. The verbosity of VHDL is quite irritating, but learning all the tricks with Karnaugh maps was fun and state diagrams seem almost natural now.

M 328K: Introduction to Number Theory (Caputo)

Ah, my last ever pure math course. For being a rather easy course, though, it really made me miss Differential Equations. I mentioned this earlier, and now I’m sure that Moore method isn’t my strong point. I love to research things just to get new ideas even and felt pretty stifled in this class. It looks like what I did learn won’t go to waste, though. I’ve been looking over the supplementary textbook for CS 336 (next semester), and many of the theorems and algorithms I’ve learned are in there.

(Note: I’m still waiting for my official grades to come out, but as I’ve calculated it: for the semester I have A’s in CS 310, CS 313k, and M 328k, and B’s in CS 315 and EE 316.
Update: I got an A in CS 315 and an A- in EE 316. Whoo!)

This is a way of teaching known as the Moore method. Instead of the standard lectures, this method allows students to experiment in a way by doing proofs and seeing how what we already know applies to new situations. We all progress at the same rate by presenting what we’ve learned in class and discussing what we did differently or anything that still doesn’t make sense.

Though this method is also used in our logic course, most computer science classes follow the standard lecture and lab format. Professor Gordon Novak told us, “CS is an experimental science,” but by this he didn’t mean that we discover new data structures just by trying to solve a problem and seeing that that would be the best possible solution. Instead with some exceptions, we learn most of the time we don’t need to reinvent the wheel. The focus is on learning about many different data structures, gaining experience using them, and figuring out how to decide which is the best solution to any particular problem.

Of course, the concept of number theory is completely different than most of what we encounter in computer science. The method of proving the theorem (which may be as close to programming as math gets) isn’t so important as the fact that you can prove it and really understand why something’s true. It’s still kind of a shock being in a Moore method class, but it’s only been two weeks, so I still have most of a semester left to see if this works for me.

Afterwards, he talked quite a bit about his main project as chair–which is to get a new building for our Computer Science department. Right now our faculty is spread across 6 different buildings, not all close to each other, and having everyone together would be great for sharing ideas, working on research, and just building a community. I frequently hang out in the basement where the ACM and WICS offices are, but it’s not convenient for most other people to just come by, and yes, it does smell a little funny. Unfortunately, the date for starting the new building still isn’t set, and it would take four years or so to complete, so it definitely won’t be up while I’m still here. I’m still not completely sure it’s necessary to take on that cost of not having a central hub for that amount of time, but the ideas Moore presented of our new building sure did sound lovely.

Another interesting idea he had was to have senior faculty teach the lower-level classes, while the newer faculty who are doing more research would be teaching the upper level classes. Personally, I think that’s a great idea since there’s nothing that turns more students off of certain classes than not having a teacher who really has teaching experience. I agree with this completely, as well as his idea to have larger class sizes using tools such as iClicker for extra interaction. My one concern with his ideas here was that of reducing reliance on lecturers. It really makes sense financially since the funds for lecturers fluctuate every year, but Mike Scott has been doing a great job of teaching CS 307 for about a decade now, and I don’t know if anyone else could fill that role so well.

Anyhow, Moore is teaching CS 313k occassionally and I don’t have him next semester, so I may never get to see how he is as a professor, but it certainly was enjoyable to have our group sit down to lunch with him and learn a bit more about what’s going on with the department.