SELinux To Do list

SELinux To Do list

[Guerra, Kamuela D.]

According to http://www.nsa.gov/selinux/todo.html there is still work to be
done on the documentation tasks.

What still needs to be done and how can I help?

---Kam Guerra

--
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: SELinux To Do list

[Stephen D. Smalley]

> According to http://www.nsa.gov/selinux/todo.html there is still work to be
> done on the documentation tasks.
> 
> What still needs to be done and how can I help?

I don't think anyone has written any of the three documents listed on the 
todo.html page.  Prior to starting to work on any such documentation, you should 
review the existing papers and technical reports available from the NSA site 
(http://www.nsa.gov/selinux/docs.html).  Tresys Technology has also written a 
few policy whitepapers, available from their site 
(http://www.tresys.com/selinux), but be aware that some things have changed 
since those whitepapers were written.

We would welcome contributions of HOWTO-style documents.  In creating such
documents, please don't start from scratch; you should be able to leverage
some of the content of the existing papers and reports.  The published
papers and older technical reports were originally written in LaTeX, and
the newer technical reports were written in DocBook.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
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: SELinux To Do list

[Faye]

On Mon, 30 Dec 2002 21:44, Stephen D. Smalley wrote:

> I don't think anyone has written any of the three documents listed on the 
> todo.html page.  Prior to starting to work on any such documentation, you should 
> review the existing papers and technical reports available from the NSA site 
> (http://www.nsa.gov/selinux/docs.html).  Tresys Technology has also written a 
> few policy whitepapers, available from their site 
> (http://www.tresys.com/selinux), but be aware that some things have changed 
> since those whitepapers were written.
> We would welcome contributions of HOWTO-style documents.  In creating such
> documents, please don't start from scratch; you should be able to leverage
> some of the content of the existing papers and reports.  The published
> papers and older technical reports were originally written in LaTeX, and
> the newer technical reports were written in DocBook.

I am part of the way through writing an introductory level HOWTO.  Hope
to have it available in a week.  Actually with New Year celebrations, I
might have to make that a week to two weeks  ;)

faye

-- 
Message from Our Sponsor on ttytv at 00:01 ...
Faye Coker			    faye@lurking-grue.org
Current stomping ground: 	    Amsterdam, The Netherlands


--
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: SELinux To Do list

[Paul Greene]

I'd be interested in writing some HOW-TO documents, or some 
administrative type guides for SELinux as a practical for a SANS 
certification.

Can you suggest some topics that would be the most useful/most needed 
for the SELinux community?

Stephen D. Smalley wrote:

>>According to http://www.nsa.gov/selinux/todo.html there is still work to be
>>done on the documentation tasks.
>>
>>What still needs to be done and how can I help?
>>    
>>
>
>I don't think anyone has written any of the three documents listed on the 
>todo.html page.  Prior to starting to work on any such documentation, you should 
>review the existing papers and technical reports available from the NSA site 
>(http://www.nsa.gov/selinux/docs.html).  Tresys Technology has also written a 
>few policy whitepapers, available from their site 
>(http://www.tresys.com/selinux), but be aware that some things have changed 
>since those whitepapers were written.
>
>We would welcome contributions of HOWTO-style documents.  In creating such
>documents, please don't start from scratch; you should be able to leverage
>some of the content of the existing papers and reports.  The published
>papers and older technical reports were originally written in LaTeX, and
>the newer technical reports were written in DocBook.
>
>--
>Stephen Smalley, NSA
>sds@epoch.ncsc.mil
>  
>




--
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: SELinux To Do list

[Kerry Thompson]

I've made a start on a technical-level FAQ, currently at 

http://www.crypt.gen.nz/selinux/faq.html

and I'm working on back-tracking through the list archives for more material. 
Any comments or corrections are most welcome. This is currently hosted on my 
DSL line, so mirrors or a more permanent site would also be appreciated.

Kerry

On Tue, 31 Dec 2002 09:44, Stephen D. Smalley wrote:
> > According to http://www.nsa.gov/selinux/todo.html there is still work to
> > be done on the documentation tasks.
> >
> > What still needs to be done and how can I help?
>
> I don't think anyone has written any of the three documents listed on the
> todo.html page.  Prior to starting to work on any such documentation, you
> should review the existing papers and technical reports available from the
> NSA site (http://www.nsa.gov/selinux/docs.html).  Tresys Technology has
> also written a few policy whitepapers, available from their site
> (http://www.tresys.com/selinux), but be aware that some things have changed
> since those whitepapers were written.
>
> We would welcome contributions of HOWTO-style documents.  In creating such
> documents, please don't start from scratch; you should be able to leverage
> some of the content of the existing papers and reports.  The published
> papers and older technical reports were originally written in LaTeX, and
> the newer technical reports were written in DocBook.


--
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: SELinux To Do list

[Russell Coker]

On Tue, 31 Dec 2002 20:43, Kerry Thompson wrote:
> I've made a start on a technical-level FAQ, currently at
>
> http://www.crypt.gen.nz/selinux/faq.html

SE Linux is as well suited to large servers as to small servers.  I suspect 
that the NSA people were thinking more of large servers than small servers 
when designing it.

If you take it to an extreme, if you have small servers that only run a single 
service each with read-only media (EG CD-ROM) for files that don't change 
then for many services (DNS, DHCP, and other simple services) SE Linux will 
not provide any benefit.  Think about a machine running only BIND where all 
files are on CD-ROM apart from /var/cache/bind which is on a ram disk, in 
that case SE Linux offers no extra benefit.

The fact that almost no-one runs such trivially small servers makes SE Linux 
useful for almost everyone IMHO.

One major difference that I percieve between the ideas that the NSA people 
have and the ideas that I and others have is the amount of customisation work 
that a typical user will perform.  The NSA people seem to regard it as 
typical for an administrator to write their own security policy.  My 
experience is that administrators typically don't know how their servers 
really work and therefore are incapable of doing much in the way of changes 
to security policy.  Therefore SE Linux is more usable by most people for 
small servers (when you can just install the default policy and have it work) 
than for complex servers (where writing policy is required).


For loading policy, "make load" will load the policy into the kernel if it 
believes that the policy needs to be loaded (IE is different from what is 
already in the kernel).  "make reload" will load the policy regardless.  This 
is useful if you have loaded a policy from some other file and wish to revert 
to the policy in /etc/security/selinux/ .


Just using newrules to make policy as you suggest results in bad policy.  It's 
best to carefully analyse what you want to do and write policy accordingly.

EG if you decide to deny an application access to a directory then you don't 
need any special policy for the files in that directory (remember it's a 
default of no access in SE Linux).  If you were to use newrules without any 
thought then you would inevitably grant access that is not desired.  If you 
use it with little thought then you would convert large numbers of "allow" 
rules in the newrules output to "dontaudit" and result in "dontaudit" 
messages for files in unreadable directories.

If an application is denied access to a directory then you don't want a 
"dontaudit" rule for files in that directory as an attempted access to such 
files may indicate another problem (such as a file handle leak from a calling 
program).


Regarding the issue of making it impossible to leave enforcing more, in 
domains/admin.te there is the following line:
auditallow admin kernel_t:system avc_toggle;
And there is a similar one in domains/program/initrc.te .  Remove those lines 
and it will not be possible to toggle back from enforcing mode (not without 
changing policy at least, and you can block that through policy too).

Note that denying avc_toggle does not stop you from entering enforcing mode if 
you boot in permissive mode (for obvious reasons ;).

Actually now that I consider this, it doesn't seem to make much sense to 
compile a kernel that doesn't support switching between enforcing and 
permissive modes.  It would make more sense to compile a kernel to default to 
enforcing (without needing a parameter).  Steve, what do you think?


Regarding upgrading the kernel and having errors booting, you don't need to 
"reload" the policy before booting, you just need to install it.  Also if you 
install a kernel with a new policy version then you need a matching policy 
and utilities, in which case running "make load" on the old kernel will fail 
(old kernel can't accept new policy), so "make install" is what you want.


Apart from those issues the FAQ is good work.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: SELinux To Do list

[Stephen D. Smalley]

> I've made a start on a technical-level FAQ, currently at 
> 
> http://www.crypt.gen.nz/selinux/faq.html
> 
> and I'm working on back-tracking through the list archives for more material. 
> Any comments or corrections are most welcome.

Thanks for creating this FAQ.  I've made a few comments below.

1) Some of your questions and answers are also covered in the Configuring the 
SELinux Policy report, http://www.nsa.gov/selinux/policy2-abs.html, in 
particular the Building and Applying the Policy section and the Customizing the 
Policy section of that report.  Feel free to use it as a resource and to refer 
people to it as well.  Please report any errors in it and feel free to submit 
patches to it (the document source is included in the selinux archive, under 
selinux/doc/policy).  

2) You can relabel a specified list of files via the -s option to setfiles 
rather than rechecking the entire filesystem.  This option was added by Russell 
Coker.

3) If you want to deny avc_toggle permission, you need to change 'allow' rules 
in the configuration, not 'auditallow' rules.  'auditallow' rules specify what 
permissions should be audited when they are allowed (granted) to a process.  By 
default, permissions are only audited when they are denied to a process (unless 
they are suppressed via 'dontaudit' rules).  You can enable auditing of allowed 
permissions via auditallow in order to maintain a record of all uses of a given 
permission, e.g. to provide accountability for a highly privileged operation.  
Removing the 'auditallow' rules merely turns off auditing when the permission is 
granted; it has no effect on allowing the permission.

To remove avc_toggle permission in the example policy, you would need to edit 
macros/admin_macros.te and replace the 'allow $1_t kernel_t:system *;' with 
'allow $1_t kernel_t:system ~avc_toggle;'.  You would also need to edit 
domains/program/initrc.te and replace the 'allow initrc_t kernel_t:system *;' 
rule with 'allow initrc_t kernel_t:system ~avc_toggle;'.  To ensure that you 
have removed all such instances, you can edit assert.te and replace 'neverallow 
~{ admin initrc_t } kernel_t:system avc_toggle;' with 'neverallow domain 
kernel_t:system avc_toggle;'.  The policy compiler (checkpolicy) will then 
verify that no domain is granted this permission and report any violations of 
this assertion when it compiles the policy.

To remove the ability to reload the policy on a running system, you would remove 
load_policy permission from all domains, and completely remove the load_policy 
domain.   As above, you can define an assertion so that checkpolicy will catch 
any exceptions to this, e.g. 'neverallow domain security_t:security 
load_policy;'.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
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: SELinux To Do list

[Stephen D. Smalley]

> Note that denying avc_toggle does not stop you from entering enforcing mode if 
> you boot in permissive mode (for obvious reasons ;).
> 
> Actually now that I consider this, it doesn't seem to make much sense to 
> compile a kernel that doesn't support switching between enforcing and 
> permissive modes.  It would make more sense to compile a kernel to default to 
> enforcing (without needing a parameter).  Steve, what do you think?

We could provide the latter (a config option to default to enforcing while 
retaining development support), without removing the former (a config option to 
completely disable development support).  I think that some users will still 
want the former, preferring to keep an entirely separate kernel from their 
production kernel that can be booted for development/maintenance operations.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
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: SELinux To Do list

[Faye]

On Mon, Dec 30, 2002 at 03:44:20PM -0500, Stephen D. Smalley wrote:
 
> We would welcome contributions of HOWTO-style documents.  In creating such
> documents, please don't start from scratch; you should be able to leverage
> some of the content of the existing papers and reports.  The published

http://www.lurking-grue.org/selinux/gettingstarted.html

It's an introductory level HOWTO.  In some parts it was quite a PITA to
work out in what order things should be listed so I hope it has ended up
clear enough.  I realise there is some backtracking in various sections.

Unfortunately I do not have a spare machine handy so I can not test out
my own instructions at this time (but I might be able to next week).  
Please let me know your comments and suggestions but bear in mind I will 
be away until Monday and unable to respond before then.

faye 

-- 
Message from Our Sponsor on ttytv at 00:01 ...
Faye Coker			    faye@lurking-grue.org
Current stomping ground: 	    Amsterdam, The Netherlands


--
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: SELinux To Do list

[Tom]

On Thu, Jan 16, 2003 at 08:37:34AM +1100, Faye wrote:
> http://www.lurking-grue.org/selinux/gettingstarted.html

This looks very helpful.

I have a company-internal course on SELinux upcoming, and was about to
write up something very similiar (though much shorter). I think I'll
stick with your HOWTO and make notes during the lecture on how well my
guys could understand and implement it.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

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