FYI SELinux/AppArmor press

FYI SELinux/AppArmor press

[Daniel J Walsh]

http://www.gcn.com/vol1_no1/daily-updates/38330-1.html


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Randal T. Rioux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Daniel J Walsh wrote:
> http://www.gcn.com/vol1_no1/daily-updates/38330-1.html
> 

Thanks for the link, and for publicizing your position.

- From your blog: "Novell claims that AppArmor is easier to use for third
parties."

Didn't Bill Gates use the same logic? I shudder when I hear statements
like that. Yes, it takes more effort and time to implement better
security. Writing your password on a Post-It and slapping it on your
monitor is easy too, but wouldn't a little creativity and effort to
memorize your access codes be better?!

Uggh. Back to lurking.

- --
Randal T. Rioux | Procyon Labs
IT Security R&D and Consulting
Virtual: www.procyonlabs.com
Physical: DC / Baltimore
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0xD08D1941


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD/+2ERrGMQdCNGUERA0o+AJ45D12GvaTJ8N+1qpz5p6VC9XDHcQCeLPgJ
q64Q6Rk3MyUa0bEBgyQOO8w=
=9wbL
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Erich Schubert]

Hello Daniel, Hello SELinux list,
I've posted a rather critical reply to the "AppArmor vs. SELinux"
discussion to my blog at http://blog.drinsama.de/erich/en/linux/selinux

In my opinion, AppArmor can indeed kill SELinux, even when it provides
much lesser security - by just incorporating the community better than
SELinux does.

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
 Nothing prevents happiness like the memory of happiness. --- A. Gide //\
     Unter Freunden ist guter Rat nicht teuer, aber wie alles, was    V_/_
         nichts kostet, nur wenig gefragt. --- Robert Muthmann


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[cwarner]

On Tue, 2006-02-28 at 16:02 +0100, Erich Schubert wrote:
> Hello Daniel, Hello SELinux list,
> I've posted a rather critical reply to the "AppArmor vs. SELinux"
> discussion to my blog at http://blog.drinsama.de/erich/en/linux/selinux
> 
> In my opinion, AppArmor can indeed kill SELinux, even when it provides
> much lesser security - by just incorporating the community better than
> SELinux does.
> 
> best regards,
> Erich Schubert

I think everyone is mostly aware of the documentation issue, that said.
Seeing as everyone keeps saying easier to use. Can you state an explicit
example please? From Crispin Corwan's slides and the constant "easier to
use" barrage I'd expect an example.

How is AppArmor easier to use? Negating the fact that I would have to
learn something new.

--
Christopher Warner


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Erich Schubert]

Hello Christopher,
Well, I'm still not running SELinux reference policy successfully.
So anything that actually works is easier to use...
E.g. if the reference policy would include a users_extra file that
labels /root
with sysadm prefix... and if that were documented anywhere and wouldn't
have required me to dive through the source of three packages.
Now if ssh login as sysadm_r would work, I'd be mostly done.

Albeit the documented interfaces of current RefPolicy are an
improvement, I don't think that policy writing has become much easier.
The M4 syntax is still very awkward (backticks, no semicolons), and
unless you've read all the policy thoroughly (e.g. because you've
written it), you'll have a hard time finding the right macros to call.
It's also very unintuitive when to use a macro/call an interface and
when not.
The current policy language is still very much "bottom up", i.e. "these
is our output, how can we generate it a bit easier", and not "top down",
i.e. "this is how we want to write the policy, how do we get a useful
output".

> How is AppArmor easier to use? Negating the fact that I would have to
> learn something new.

I've never looked at AppArmor, I've been using "old" strict SELinux for
some time, so I'd prefer to get the "new" modular SELinux work... I had
experimented with grctl1 ACL some time, which I guess are similar to
what AppArmor does. And I've seen the benefits of labeled processes and
transitions, so I'd like to stick with them.

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
   There was never a good war or a bad peace. - Benjamin Franklin   //\
           Ein schöner Moment leuchtet das Leben hindurch.          V_/_



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Benjy Grogan]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On 3/1/06, Erich Schubert <erich@debian.org> wrote:
>
> Hello Christopher,
> Well, I'm still not running SELinux reference policy successfully.
> So anything that actually works is easier to use...
> E.g. if the reference policy would include a users_extra file that
> labels /root
> with sysadm prefix... and if that were documented anywhere and wouldn't
> have required me to dive through the source of three packages.
> Now if ssh login as sysadm_r would work, I'd be mostly done.
>
> Albeit the documented interfaces of current RefPolicy are an
> improvement, I don't think that policy writing has become much easier.
> The M4 syntax is still very awkward (backticks, no semicolons), and
> unless you've read all the policy thoroughly (e.g. because you've
> written it), you'll have a hard time finding the right macros to call.
> It's also very unintuitive when to use a macro/call an interface and
> when not.
> The current policy language is still very much "bottom up", i.e. "these
> is our output, how can we generate it a bit easier", and not "top down",
> i.e. "this is how we want to write the policy, how do we get a useful
> output".


How do these new IDEs that Tresys put out in the last week or so fit into
the picture?  Haven't used them, but they appear to be the start of a
higher-level approach to developing policy and perhaps more intuitive.  I'm
talking about SLIDE (SELinux policy IDE) and the CDS framework IDE tool.

Benji

[-- Attachment #2: Type: text/html, Size: 1816 bytes --]

Re: FYI SELinux/AppArmor press

[Erich Schubert]

Hi Benjy,
> How do these new IDEs that Tresys put out in the last week or so fit
> into the picture?  Haven't used them, but they appear to be the start
> of a higher-level approach to developing policy and perhaps more
> intuitive.  I'm talking about SLIDE (SELinux policy IDE) and the CDS
> framework IDE tool. 

They replace vim, if you are developing your policy on a system with
eclipse installed...

SLIDE IMHO does not address the issues with the policy language, but it
just tries to make it a little bit less painful, by basically giving you
tab completion, reference (like the website did) and a couple of
templates (like policygentool did). So it likely is a nice tool for
people who _already_ know how to write policy by heart.

Have a look for example at
http://selinux-ide.sourceforge.net/images/screenshots/completion.png
well, it's nice syntax highlighting, and you have a dropdown to select
the macros. But that doesn't really help you finding the appropriate
macros, or explain what ever "generic files in library directories"
might be. Or help you finding out whether you might need it.
There are approximately 1600 interfaces, not counting the generated
network port and interface macros. Even given the hierarchy represented
by {admin,services,...} and convetions like files_ etc. names this is
probably more than most people can handle.

I can't say much about CDS: the website gives so few details, you can
barely tell what it is _meant_ to be, not to say what it's capable of. I
just don't have the time to download the sourcecode and try it. The
screenshot appears pretty at first sight, but there is nothing on it how
this interfaces with other parts of the system and other services -
which is exactly where it gets messy and complicated... Stuff like
allowing DNS usage, access to locales. Using the perl interpreter, or
python. Reading /etc/resolv.conf. Some of this has matching interfaces
already, some has not.
I guess you could even autodetect some of these things. A smart
policygen tool should be able to detect whether it needs
perl/python/java/mono, maybe locales, maybe you could just grep for
"ifconfig" in the binary, too...

best regards,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
      To be trusted is a greater complement than to be loved.       //\
   Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum    V_/_
                beschrieben hat. --- Galileo Galilei


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Chad Sellers]

Erich Schubert wrote:
> Hi Benjy,
> 
>>How do these new IDEs that Tresys put out in the last week or so fit
>>into the picture?  Haven't used them, but they appear to be the start
>>of a higher-level approach to developing policy and perhaps more
>>intuitive.  I'm talking about SLIDE (SELinux policy IDE) and the CDS
>>framework IDE tool. 
> 
> 
Erich,

I'm sorry you're having trouble with reference policy and libsemanage.
They're still a work in progress, and will continue to improve in the
near future. We definitely appreciate your efforts to get this working
on Debian, as we want to see this used in as many distributions as
possible. Fedora and Gentoo are a good start, but we'd like to see it
keep spreading.

> They replace vim, if you are developing your policy on a system with
> eclipse installed...
> 
> SLIDE IMHO does not address the issues with the policy language, but it
> just tries to make it a little bit less painful, by basically giving you
> tab completion, reference (like the website did) and a couple of
> templates (like policygentool did). So it likely is a nice tool for
> people who _already_ know how to write policy by heart.
> 
> Have a look for example at
> http://selinux-ide.sourceforge.net/images/screenshots/completion.png
> well, it's nice syntax highlighting, and you have a dropdown to select
> the macros. But that doesn't really help you finding the appropriate
> macros, or explain what ever "generic files in library directories"
> might be. Or help you finding out whether you might need it.
> There are approximately 1600 interfaces, not counting the generated
> network port and interface macros. Even given the hierarchy represented
> by {admin,services,...} and convetions like files_ etc. names this is
> probably more than most people can handle.
> 
Reference policy is less painful, but the mechanisms it provides are the
real power that will allow us to make things easier. We've been trying
to make policy development easier for some time, and we eventually
realized that we couldn't do it without better structure in the policy.
Now that we're starting to have that structure, we can use that to build
higher-level abstractions. These can be as simple as more abstract
interfaces or as complex as higher-level languages and tools. The CDS
Framework is one early example of this which is fairly specific to a
given environment.

SLIDE is a very early version of a reference policy IDE (that's why it's
version 0.1). We're hoping to make it much easier to use over time, but
we wanted to develop it in the open-source so that we could at least get
continuous feedback on it. Even at 0.1, we've gotten some very positive
feedback regarding the features that it does provide.

> I can't say much about CDS: the website gives so few details, you can
> barely tell what it is _meant_ to be, not to say what it's capable of. I
> just don't have the time to download the sourcecode and try it. The
> screenshot appears pretty at first sight, but there is nothing on it how
> this interfaces with other parts of the system and other services -
> which is exactly where it gets messy and complicated... Stuff like
> allowing DNS usage, access to locales. Using the perl interpreter, or
> python. Reading /etc/resolv.conf. Some of this has matching interfaces
> already, some has not.
> 
Just to fill in some of the details here, CDS Framework does have
provisions for linking to the base system. I'm sorry that it is
currently not very well documented. There is actually a paper being
presented at the SELinux Symposium tomorrow on our experiences
implementing the CDS Framework language, including the difficulties with
linking to a base system. I'll make sure at least the presentation makes
it to the web.

Thanks,
Chad

-- 

----------------------
Chad Sellers
Tresys Technology, LLC
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Erich Schubert]

Hello Chad,
In my opinion, the SELinux security policy should be done using a real
OOP paradigma, not this "imperative" like set of rules we have right now
(M4 is imperative...)
In an ideal case, people could write SELinux policies using UML
modelers.
I'm not a big fan of Java and UML, but I think it helps people a lot.

We had some OOP-like elements alaredy - "sysadmfile" and similar type
flags we had in the old nsa policy.

I'd imagine a good policy language to be like this:
---
type system_logfile : public system_file {
	public interface read { ... }
	public interface write { ... }
	public interface append { ... }
	public interface manage { ... }
}

type amavis_logfile : public system_logfile {
	match "/var/log/amavis.*"
	/* will inherit interfaces by system_logfile */
}

type amavisd_exec : public system_executable_file {
	match "/usr/sbin/amavisd.*"

	interface execTransition { ... }
}

type amavisd : public network_daemon {
	interface sendTo { ... }
}

rules amavisd {
	allow appendTo amavis_logfile
}

rules initrc {
	allow execTransition amavisd_exec
}
---

I'm no language designer, and no usability expert... but I think the
policy language should avoid unnecessary repetition as far as possible
and follow modelling paradigmas people already know such as inheritance.

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
 Why waste time learning, when ignorance is instantaneous? --- Calvin //\
              Es lohnt sich nicht, die Augen aufzumachen,             V_/_
                     wenn der Kopf im Sand steckt.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Joshua Brindle]

Erich Schubert wrote:
> Hello Chad,
> In my opinion, the SELinux security policy should be done using a real
> OOP paradigma, not this "imperative" like set of rules we have right now
> (M4 is imperative...)
> In an ideal case, people could write SELinux policies using UML
> modelers.
> I'm not a big fan of Java and UML, but I think it helps people a lot.
>

I'll start by saying I've been spending alot of time thinking about 
language enhancements lately and will be sending an RFC to the list 
sometime soon. With that in mind I have some comments on these suggestions.

> We had some OOP-like elements alaredy - "sysadmfile" and similar type
> flags we had in the old nsa policy.
> 
> I'd imagine a good policy language to be like this:
> ---
> type system_logfile : public system_file {
> 	public interface read { ... }
> 	public interface write { ... }
> 	public interface append { ... }
> 	public interface manage { ... }
> }

the reference policy is designed so that modules don't know about types 
(or any symbol) from other modules. Instead the reference policy tries 
to abstract them into actions relevant to that module such as 
apache_read_log. The webalizer module knows it needs to read apache 
logs, but doesn't need to know how that is implemented. This kind of 
encapsulation is one of the best benefits of refpolicy IMHO.

> 
> type amavis_logfile : public system_logfile {
> 	match "/var/log/amavis.*"
> 	/* will inherit interfaces by system_logfile */
> }
> 
putting labeling with the policy is bad for a few reasons. First the 
file context files are suppose to be for system initialization only, 
though they aren't necessarily used that way. Further, different distros 
(and even different OS's) are going to have different file paths which 
would require that information to be encoded into the policy instead of 
letting the enforcement policy be separate from labeling.

> type amavisd_exec : public system_executable_file {
> 	match "/usr/sbin/amavisd.*"
> 
> 	interface execTransition { ... }
> }
> 
> type amavisd : public network_daemon {
> 	interface sendTo { ... }
> }
> 
> rules amavisd {
> 	allow appendTo amavis_logfile
> }
>
Not sure things like this fix anything. You would still have to know 
about something called "amavis_logfile", how is that different from 
looking at http://serefpolicy.sourceforge.net/api-docs/ and going to the 
amavis module and seeing the available interfaces (or using SLIDE with 
autocomplete)

> rules initrc {
> 	allow execTransition amavisd_exec
> }

It seems like this would be more verbose, lots of rules are handled by 
way of attributes which this seems to ignore.

> ---
> 
> I'm no language designer, and no usability expert... but I think the
> policy language should avoid unnecessary repetition as far as possible
> and follow modelling paradigmas people already know such as inheritance.
> 

inheritance is great while programming when you can apply repetitive 
procedures to similar classes. Inheritance with security is not good, 
however. In an ideal world children would be reducing policy, not 
applying the same.

Other than those I agree that OOP principles could do wonders for policy 
development and I'm collecting ideas like these for the language 
discussion at the developers summit tomorrow, stay tuned for published 
notes from there.

We also had a couple papers in the symposium proceedings regarding 
language abstractions and I think there are lots of good ideas being 
bounced around and now we need to take those and figure out which ones 
are truly helpful and implement them.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[Erich Schubert]

Hello Joshua, Chad, Hello SELinux list,

What I'd really appreciate would be a security modelling approach which
can be visualized like this:
http://www.mucl.de/~erich/selinux-oop-example.png
It's debatable whether you want e.g. any webserver to write any httpd
logfile.
But this is a true preference question - it's simpler if you have only
one domain for httpd logfiles (and that is fine as long as you have only
one web server running); you could also do a "generic httpd logfile"
which is writeable by all web servers and specialized "disjoint"
logfiles when needed. Or you can require httpd servers to define their
own domain and grant access rights only on that level (labeled "variant
2" in the diagram above).
A language can't solve this question, but it can make it easier to see.

> the reference policy is designed so that modules don't know about types 
> (or any symbol) from other modules. Instead the reference policy tries 
> to abstract them into actions relevant to that module such as 
> apache_read_log. The webalizer module knows it needs to read apache 
> logs, but doesn't need to know how that is implemented. This kind of 
> encapsulation is one of the best benefits of refpolicy IMHO.

I agree that this is a good approach. However, this can still be solved
by inheritance. For example, you could grant webalizer access to
apache_logfiles, which is actually an "abstract" type, realized by two
other types "apache_access_logs" and "apache_error_logs".

> putting labeling with the policy is bad for a few reasons. First the 
> file context files are suppose to be for system initialization only, 

They also are an important reference and documentation thing. In order
to understand policy, it's very useful to see which parts of the system
are supposed to be labeled this way.
On my systems, I basically want all files except (partially) /home
and /tmp
to be labele exactly as given by this "initial" labelling.
Right now, the separation achieved is pretty minimal (well, same file
name except for two letters) but it requires me to work with two files,
even when I'm actually working on one thing (e.g. the apache logfiles)

I definitely prefer having all apache logfile related stuff in one
place, instead of having all the apache domain stuff in apache.te and
apache.if and the files in apache.fc
And this was worse with the old policy, where they were even in separate
directories...

> though they aren't necessarily used that way. Further, different distros 
> (and even different OS's) are going to have different file paths which 
> would require that information to be encoded into the policy instead of 
> letting the enforcement policy be separate from labeling.

Right now I think we'll even have to patch the policy for specific
distros. Patching initial file labeling is not that much more work.
Especially "additional" labels - and that is a common case - can be
treated specially anyway. And we'll probably have some case construct in
there, too.
So from my "debian packaging" standpoint I don't see issues here.

> Not sure things like this fix anything. You would still have to know 
> about something called "amavis_logfile", how is that different from 
> looking at http://serefpolicy.sourceforge.net/api-docs/ and going to the 
> amavis module and seeing the available interfaces (or using SLIDE with 
> autocomplete)

I think the syntax is compacter, which is good. Less to read means
easier to write and to verify. And OOP is targeting this, too, by being
able to define rights on "higher" types and inheriting them here.

> inheritance is great while programming when you can apply repetitive 
> procedures to similar classes. Inheritance with security is not good, 
> however. In an ideal world children would be reducing policy, not 
> applying the same.

SELinux policy writing is _very_ repetitive. Which is bad.
Inheritance in security is good, because you can just write down the
_differences_ between two domains, and that makes them easier to check.
And if you want a complete description of what a domain can do, you can
still flatten them. All you need is a tool that "concatenates" the
access rights. They'll probably even remain nicely grouped "inherited
from class xyz: a,b,c"
so you'll even know where to fix it.

> We also had a couple papers in the symposium proceedings regarding 
> language abstractions and I think there are lots of good ideas being 
> bounced around and now we need to take those and figure out which ones 
> are truly helpful and implement them.

Thats something I don't like too much about the symposium - it looks
like a lot of stuff is/was basically "held back" to present it at the
symposium.

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
   It's not denial. I'm just selective about the reality I accept.   //\
    Die Freunde nennen sich aufrichtig. Die Feinde sind es: Daher    V_/_
      man ihren Tadel zur Selbsterkenntnis benutzen sollte, als
            eine bittere Arznei.  --- Arthur Schopenhauer


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: FYI SELinux/AppArmor press

[coderman]

On 3/3/06, Erich Schubert <erich@debian.org> wrote:
> ...
> I agree that this is a good approach. However, this can still be solved
> by inheritance. For example, you could grant webalizer access to
> apache_logfiles, which is actually an "abstract" type, realized by two
> other types "apache_access_logs" and "apache_error_logs".

inheritance and least privilege is difficult; this might be something
to discuss in more detail with a constraint model applied to ensure
that an inheritance hierarchy does not leak excessive and unnecessary
privileges.  has this been discussed before on the devel list?

"Integrated constraints and inheritance in DTAC"
http://portal.acm.org/citation.cfm?id=344307

"The Role-Based Access Control System of a European Bank: A Case Study
and Discussion"
http://www-users.cs.york.ac.uk/~jeremy/papers/SACMAT2001.pdf


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.