* Re: Life cycle process for building products with selinux
2010-05-05 14:22 Life cycle process for building products with selinux Alan Rouse
@ 2010-05-05 15:15 ` Daniel J Walsh
2010-05-05 15:47 ` Xavier Toth
2010-05-05 18:25 ` Karl MacMillan
2010-05-06 0:12 ` James Morris
2 siblings, 1 reply; 5+ messages in thread
From: Daniel J Walsh @ 2010-05-05 15:15 UTC (permalink / raw)
To: Alan Rouse; +Cc: selinux@tycho.nsa.gov
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/05/2010 10:22 AM, Alan Rouse wrote:
> I'm not sure where to ask a question like this but I bet someone on the list will know...
>
> Are there any guidelines or "best practices" for building products with selinux? (Think network appliances for example.) I have in mind life cycle tasks such as
>
I would argue as early in the process as possible. From a security
point of view, I would specify your security goals during your design
phase and then write preliminary policy to implement them.
> - Software development: Where in the software development cycle do you introduce selinux? Should application developers have to develop on a system confined by selinux? Is selinux policy maintenance a software development task, or a separate phase in the development cycle?
>
Yes it should be a development task, BUT some one with knowledge of
security should review the policy. Most developers are just going to
want to get SELinux out of the way, so they will write as close to
unconfined_t policy as they can get away with. Developers will get
continually frustrated by mislabeling though. For example a binary has
a label of myapp_exec_t, every time the developer replaces the app, he
must make sure it has the label on it. Also SELinux makes debugging
more difficult. For example if you are writing a daemon application the
policy will probably have something like
unconfined_t -> initrc_exec_t @> initrc_t -> myapp_exec_t @> myapp_t
So an admin executing service myapp start will transition properly,
but
unconfined_t -> myapp_exec_t @> unconfined_t
Which means a admin executing the daemon directly or via gdm will stay
in the same context as the admin.
You can hook up to a running process with gdm or use runcon to make sure
the app runs within the correct context.
> - System integration: Is this where selinux is first turned on?
>
It can be, but some major design decisions might have been made that
cause confinement to be more difficult and may cause you to need to
redesign.
> - QA testing: should QA testing include selinux-specific penetration testing? Any guidelines or examples of how this is done? Any tools?
>
I would argue this should happen with or without SELinux. Sorry no
guidelines.
> - Who in the development organization needs selinux expertise?
>
Developers and QA people need to know to look for AVC messages. But you
probably only need one person to understand how to write policy.
> - Are there services that can certify the MAC rules for the operating system? For the product application?
>
> - Any selinux-specific guidance for customers who install the protected appliance?
>
I think you want to run with permissive domains, for a while to catch
all of the code paths that you did not expect, without the SELinux
causing the application to break.
> - Impact on the process for upgrades and patches because of selinux. What not to do... for example, turning off selinux to apply a patch. How to configure a properly confined user for applying patches.
>
Yes having to turn off SELInux is a mistake, SELinux policy should be
able to be updated without major problems. Verifying labels can be a
critical part of the update.
> - Organizational policy to complement a properly designed system (separation of duties; physical security; etc).
>
> - War stories, lessons learned... or anything of the sort
>
> Thanks
> Alan
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvhi5QACgkQrlYvE4MpobM14ACghN3TMxeIASK1mxsosYfTPd++
sq0AnRGzsKRgLYytT01EwJSIZvfZbcd0
=33rj
-----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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Life cycle process for building products with selinux
2010-05-05 15:15 ` Daniel J Walsh
@ 2010-05-05 15:47 ` Xavier Toth
0 siblings, 0 replies; 5+ messages in thread
From: Xavier Toth @ 2010-05-05 15:47 UTC (permalink / raw)
To: Alan Rouse, selinux@tycho.nsa.gov; +Cc: Daniel J Walsh
On Wed, May 5, 2010 at 10:15 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/05/2010 10:22 AM, Alan Rouse wrote:
>> I'm not sure where to ask a question like this but I bet someone on the list will know...
>>
>> Are there any guidelines or "best practices" for building products with selinux? (Think network appliances for example.) I have in mind life cycle tasks such as
>>
> I would argue as early in the process as possible. From a security
> point of view, I would specify your security goals during your design
> phase and then write preliminary policy to implement them.
Agreed, it part of your requirements.
>> - Software development: Where in the software development cycle do you introduce selinux? Should application developers have to develop on a system confined by selinux? Is selinux policy maintenance a software development task, or a separate phase in the development cycle?
>>
> Yes it should be a development task, BUT some one with knowledge of
> security should review the policy. Most developers are just going to
> want to get SELinux out of the way, so they will write as close to
> unconfined_t policy as they can get away with. Developers will get
> continually frustrated by mislabeling though. For example a binary has
> a label of myapp_exec_t, every time the developer replaces the app, he
> must make sure it has the label on it. Also SELinux makes debugging
> more difficult. For example if you are writing a daemon application the
> policy will probably have something like
> unconfined_t -> initrc_exec_t @> initrc_t -> myapp_exec_t @> myapp_t
>
> So an admin executing service myapp start will transition properly,
> but
>
> unconfined_t -> myapp_exec_t @> unconfined_t
>
> Which means a admin executing the daemon directly or via gdm will stay
> in the same context as the admin.
>
> You can hook up to a running process with gdm or use runcon to make sure
> the app runs within the correct context.
>
>
>
It is a development task because you really need to understand what
code is doing to write policy. Some of us develop and test on the same
system but I prefer having separate development and test systems (can
be VMs).
Classic line: "It works in permissive." Sorry, this means nothing!
>> - System integration: Is this where selinux is first turned on?
>>
> It can be, but some major design decisions might have been made that
> cause confinement to be more difficult and may cause you to need to
> redesign.
>> - QA testing: should QA testing include selinux-specific penetration testing? Any guidelines or examples of how this is done? Any tools?
>>
> I would argue this should happen with or without SELinux. Sorry no
> guidelines.
>> - Who in the development organization needs selinux expertise?
>>
> Developers and QA people need to know to look for AVC messages. But you
> probably only need one person to understand how to write policy.
Yes you'll have to get QA to look at AVCs and have some understanding.
>> - Are there services that can certify the MAC rules for the operating system? For the product application?
Ah... the holy grail when you find it tell me.
>>
>> - Any selinux-specific guidance for customers who install the protected appliance?
>>
> I think you want to run with permissive domains, for a while to catch
> all of the code paths that you did not expect, without the SELinux
> causing the application to break.
>> - Impact on the process for upgrades and patches because of selinux. What not to do... for example, turning off selinux to apply a patch. How to configure a properly confined user for applying patches.
>>
> Yes having to turn off SELInux is a mistake, SELinux policy should be
> able to be updated without major problems. Verifying labels can be a
> critical part of the update.
We only ever boot 'enforcing=0 single' to update setrans.conf
otherwise you never want to do this.
>> - Organizational policy to complement a properly designed system (separation of duties; physical security; etc).
>>
>> - War stories, lessons learned... or anything of the sort
Audit is a big deal.
>>
>> Thanks
>> Alan
>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvhi5QACgkQrlYvE4MpobM14ACghN3TMxeIASK1mxsosYfTPd++
> sq0AnRGzsKRgLYytT01EwJSIZvfZbcd0
> =33rj
> -----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.
>
Ted
--
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Life cycle process for building products with selinux
2010-05-05 14:22 Life cycle process for building products with selinux Alan Rouse
2010-05-05 15:15 ` Daniel J Walsh
@ 2010-05-05 18:25 ` Karl MacMillan
2010-05-06 0:12 ` James Morris
2 siblings, 0 replies; 5+ messages in thread
From: Karl MacMillan @ 2010-05-05 18:25 UTC (permalink / raw)
To: Alan Rouse; +Cc: selinux@tycho.nsa.gov
On Wed, May 5, 2010 at 10:22 AM, Alan Rouse <alan.rouse@ericsson.com> wrote:
> I'm not sure where to ask a question like this but I bet someone on the list
> will know…
>
> Are there any guidelines or "best practices" for building products with
> selinux? (Think network appliances for example.) I have in mind life
> cycle tasks such as
>
> - Software development: Where in the software development cycle do you
> introduce selinux? Should application developers have to develop on a
> system confined by selinux?
How we do this depends on the development team. When the team is
unfamiliar with SELinux then I believe that it's best to turn on
enforcement as early as possible so that developers start to
understand what is going to happen.
For our internal development projects - which are often appliances -
we actually design the system with SELinux in mind but don't worry
about writing policy right at the beginning. We can get away with this
because the way we use SELinux is often a key feature of the design
and everyone on the development team has a very thorough understanding
of how the enforcement will happen.
> Is selinux policy maintenance a software
> development task, or a separate phase in the development cycle?
>
We always treat it as software development. Doing too early is not
useful because the applications aren't well formed enough and doing it
after primary development doesn't catch coding errors that would
require overly permissive policy.
> - System integration: Is this where selinux is first turned on?
>
We always have SELinux on, but leave it in permissive all the way past
the initial integration steps. We still experiment with the right
point to switch to enforcing, but currently leave it until a build or
two that has been run all the way through the integration tests. We
also have a mechanism for testers to switch to permissive and re-run
tests to get better diagnostics.
> - QA testing: should QA testing include selinux-specific penetration
> testing? Any guidelines or examples of how this is done? Any tools?
>
We rely more on policy analysis rather than penetration testing, but
this requires a clear, documented set of security goals and expertise
to compare the policy against those goals. We use setools for the
analysis.
> - Who in the development organization needs selinux expertise?
>
Our situation is a bit unusual, but at Tresys every developer has good
knowledge of security and SELinux. We find this enormously beneficial
and we can justify the investment because security is key to our
business. Obviously not everyone has that benefit.
When we help teams where the knowledge of SELinux is more mixed there
are a variety of challenges. The hardest is helping developers
understand how to design software to maximize the benefit of MAC. So
many developers with security knowledge are overly focused on correct
code that privilege separation and limiting process trust are foreign
concepts. If you can't have everyone in the organization be
knowledgeable, then I would suggest teaching people about the big
picture concepts, how to switch to permissive, and how to read and
minimally interpret AVCs. That get's people to buy into using SELinux
and lets them provide good debugging information.
Without that context, SELinux can become a scapegoat for all hard to
explain bugs. Letting people quickly determine for themselves if
SELinux is to blame can avoid a lot of frustration.
> - Are there services that can certify the MAC rules for the operating
> system? For the product application?
>
Do you mean in an automated way? Not really - there is no substitute
for a knowledgeable person reviewing the policy. If you mean
professional services, we (Tresys) do system and policy analysis and I
know others do as well.
> - Any selinux-specific guidance for customers who install the protected
> appliance?
>
Depends on how much of an appliance it is. If there is a shell or the
possibility of installing software, then we give SELinux guidance in
documentation. Otherwise we just collect AVCs with other log
information for diagnostics.
> - Impact on the process for upgrades and patches because of selinux. What
> not to do… for example, turning off selinux to apply a patch. How to
> configure a properly confined user for applying patches.
>
It's very, very difficult to give an admin access to only apply
patches if you don't want them to have arbitrary access to the system.
Even restricting packages to only signed packages is hard. We just
patch with SELinux on from a domain with sufficient privilege and test
the updates before releasing them. Only rarely should there be a
problem - only if the installation of the upgrade requires a policy
change.
> - Organizational policy to complement a properly designed system (separation
> of duties; physical security; etc).
>
Most of the systems we design are installed in locations where these
policies are already in place. Role separation is something that it
would be nice to see get easier in SELinux.
> - War stories, lessons learned… or anything of the sort
>
Admins and users are always much harder than anything else - the
variety in how admins accomplish similar tasks still surprises me and
makes the policy more complex.
It's possible to lock systems down until they are irritating or
impossible debug - we tend to always leave the ability to get to a
permissive mode but protect it with policy, grub passwords, etc.
During testing it's nice to have this unlock automated.
When there are policy problems, it's best to switch to permissive and
exercise the system thoroughly. Going through many fix, build,
install, test iterations to fix policy bugs can eat up a lot of time.
Raw audit messages are much better than audit2allow output.
Installing a fully custom policy in an automated way on existing
distributions is harder than it should be - basically you are going
to be forced into a full relabel on initial boot because of
differences between the policy during installation and on the actual
system.
Karl
> Thanks
> Alan
>
--
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Life cycle process for building products with selinux
2010-05-05 14:22 Life cycle process for building products with selinux Alan Rouse
2010-05-05 15:15 ` Daniel J Walsh
2010-05-05 18:25 ` Karl MacMillan
@ 2010-05-06 0:12 ` James Morris
2 siblings, 0 replies; 5+ messages in thread
From: James Morris @ 2010-05-06 0:12 UTC (permalink / raw)
To: Alan Rouse; +Cc: selinux@tycho.nsa.gov
On Wed, 5 May 2010, Alan Rouse wrote:
> - Software development: Where in the software development cycle do you
> introduce selinux? Should application developers have to develop on a
> system confined by selinux? Is selinux policy maintenance a software
> development task, or a separate phase in the development cycle?
>
> - System integration: Is this where selinux is first turned on?
In a successful case I'm aware of, all updates to applications are tested
on a staging system before being rolled out, at which point SELinux is
enabled in permissive mode. Any AVCs are treated as regressions and the
developers work with sysadmins/security folk to either fix the application
or update the system security policy.
> - War stories, lessons learned... or anything of the sort
It would be great to see something like the above written up as a case
study -- for various reasons, people are not always in an ideal position
to do so.
--
James Morris
<jmorris@namei.org>
--
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.
^ permalink raw reply [flat|nested] 5+ messages in thread