Core policy

Core policy

[Wayne Salamon]

  I would like some feedback from the list in order to begin paring back
the SELinux example policy for a smaller 'core'. The idea is that other
portions of the policy considered non-core will be in a directory whose
files are not built into the core by default.

Here is a list of policy files that may considered the core policy.
However, this policy needs some work in order to build, but I'm trying to
get a feel for what users typically run on their systems.

The inclusion of a file should be determined by the needs of the system
and what programs are expected to be run, and other needs of the system
software (network interfaces, for example). The base platform is assumed
to be a capable Linux workstation with few optional services.

The X Windows related domains have been listed separately.

domains/program (with corresponding file_contexts/program)
==========================================================
apache.te	Apache Web server; may need to be simplified to allow only
		serving Web pages without CGI, etc.
apmd.te		Automatic Power Management daemon
atd.te 		Atd server
automount.te	Automount daemon
bootloader.te	Lilo boot loader/manager
cardmgr.te	PCMCIA control programs
checkpolicy.te	SELinux policy compliler
chkpwd.te	PAM password checking programs
crond.te	Crond daemon
crontab.te	Crontab manipulation programs
cups.te		Common Unix Printing System
devfsd.te	Control daemon for devfs device file system
dhcpc.te	DHCP client
fsadm		Disk and file system administration
getty.te	Manage ttys
gpm.te		General Purpose Mouse driver
hotplug.te	Hardware event manager
hwclock.te	Hardware clock manager
ifconfig.te	Configure network interfaces
inetd.te	Internet services daemon
init.te		Process initialization
initrc.te	System initialization scripts
ipchains.te	IP packet filter administration
klogd.te	Kernel log daemon
ldconfig.te	Configure dynamic linker bindings
load_policy.te	Policy loading utilities
login.te	Local/remote login utilities
logrotate.te	Rotate log files
lpr.te		Print client
modutil.te	Dynamic module utilities
mount.te	Filesystem mount utilities
netscape.te	Web browser (most of the policy is in a macros file)
netutils.te	Network utilities (could be removed)
newrole.te	SELinux utility to run a shell with a new role
pamconsole.te	PAM console
passwd.te	Password utilities
ping.te		Send ICMP messages to network hosts
portmap.te	Maintain RPC program number map
portslave.te	Terminal server software (not sure about this one)
pppd.te		PPP daemon
procmail.te	Mail delivery agent for mail servers (may be removed)
pump.te		DHCP client
rlogind.te	Remote login daemon (can remove; shouldn't run rlogin anyway)
rpcd.te		RPC daemon (not sure; how often do client workstations export
		RPC services)
rpm.te		Red Hat package management
rshd.te		RSH daemon (can remove; shouldn't run rsh anyway)
selopt.te	SELinux ip labeling utilities (can be removed; should only
		be installed when experimenting with labeled packets)
setfiles.te	SELinux filesystem labeling utilities
sound.te	Sound utilities
ssh.te		SSH daemon and ssh command
su.te		Run shells with substitute user and group (most of the policy
		is contained in su_macros.te
sxid.te		SUID/SGID program monitoring
syslogd.te	System log daemon
tmpreaper.te	Monitor and maintain temporary files
usbmodules.te	List kernel modules for USB devices
useradd.te	Manage system user accounts
utempter.te	Privileged helper for utmp/wtmp updates


X Windows potential core domains
==================================================
xauth.te	X authority file utility
xdm.te		X Display Manager
xfs.te		X font server
xserver.te	X Server

Macros
======
The use of macros has grown to be a large problem. The current policy makes use
of macros that call other macros which call macros. Some macros should be
eliminated; every_domain, every_test_domain for example. Others should be
pared down to least privilege; the xx_file_perms and xx_dir_perms for example.
The use of parameterized macros makes it very difficult to analyze the policy
source files. Also, there are several instances of rules being duplicated
in the generated policy due to macro usage.

-- 
Wayne Salamon
wsalamon@tislabs.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: Core policy

[Russell Coker]

On Mon, 24 Feb 2003 19:55, Wayne Salamon wrote:
> Here is a list of policy files that may considered the core policy.
> However, this policy needs some work in order to build, but I'm trying to
> get a feel for what users typically run on their systems.

I think that you need to firstly define "core" more clearly.

In previous discussions about core policy I always thought it was the packages 
needed for booting and for base functionality.  I don't think that such 
criteria matches your list of packages.

> apache.te	Apache Web server; may need to be simplified to allow only
> 		serving Web pages without CGI, etc.

Most workstations do not need Apache.  The suggestion of separating out the 
CGI part is a good one.  I will investigate it.

> apmd.te		Automatic Power Management daemon
> cardmgr.te	PCMCIA control programs

Perhaps we should have different groupings of policy?  apmd.te and cardmgr.te 
go together.  It's quite rare to use one without the other.

> cups.te		Common Unix Printing System
> lpr.te		Print client

Do we need choices in the core policy?  Maybe we should make one the 
recommended option and the other the optional replacement.

> dhcpc.te	DHCP client
> pump.te		DHCP client

I think that whatever pump needs should be merged into dhcpc.te.  There isn't 
that much a DHCP client can do, so there isn't a need to have two policy 
files IMHO.  Maybe a bit of ifdef in the policy for some of the less used 
features, but that's all.

> gpm.te		General Purpose Mouse driver

GPM is not suitable for core IMHO.  I've never used it or seen anyone use it.

> portslave.te	Terminal server software (not sure about this one)

Portslave is not needed for core policy.  The vast majority of Linux machines 
are not running as terminal servers.

> procmail.te	Mail delivery agent for mail servers (may be removed)

It's a server-only thing, IMHO it's claim is exactly as good as that of 
Apache.

> rpcd.te		RPC daemon (not sure; how often do client workstations export
> 		RPC services)

Also using rpc without care is a huge security risk.  If you want a secure 
system then removing RPC is often a good thing to do.

> X Windows potential core domains
> ==================================================
> xdm.te		X Display Manager
> xfs.te		X font server

xfs is not required IMHO.  I think that the only need for XFS is for TrueType 
fonts, and I get the impression that anti-aliasing benefits from this too.  
But the core functionality is fine without it.

As for xdm, it currently doesn't work properly and has excessive permissions.  
I'm working on this now, I expect to have it sorted out in a couple of weeks 
along with a patch for kdm 3.1.

> the policy source files. Also, there are several instances of rules being
> duplicated in the generated policy due to macro usage.

Duplication of rules is a minor annoyance, and I've been fixing it wherever I 
notice it.  But is it a big problem?  The compiler removes that anyway...

-- 
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: Core policy

[Tom]

On Mon, Feb 24, 2003 at 08:59:51PM +0100, Russell Coker wrote:
> > gpm.te		General Purpose Mouse driver
> 
> GPM is not suitable for core IMHO.  I've never used it or seen anyone use it.

Isn't gpm required by vim in Debian? If it's installed per default,
even if not used, the policy should be there.


> xfs is not required IMHO.  I think that the only need for XFS is for TrueType 
> fonts, and I get the impression that anti-aliasing benefits from this too.  
> But the core functionality is fine without it.

I use xfs-tt on my workstations, and you're correct, the main reason is
anti-aliasing. Both machines work just fine without xfs.


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

Re: Core policy

[Brian May]

On Mon, Feb 24, 2003 at 11:51:17PM +0100, Tom wrote:
> On Mon, Feb 24, 2003 at 08:59:51PM +0100, Russell Coker wrote:
> > > gpm.te		General Purpose Mouse driver
> > 
> > GPM is not suitable for core IMHO.  I've never used it or seen anyone use it.
> 
> Isn't gpm required by vim in Debian? If it's installed per default,
> even if not used, the policy should be there.

No, I don't think it is required.

vim is linked against libgpmg1, but I would imagine libgpmg1 acts
as a NOP if gpm is not running.

I think it is possible to install vim and libgpmg1 without installing
gpm (but correct me if I am wrong).
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: Core policy

[Russell Coker]

On Mon, 24 Feb 2003 23:51, Tom wrote:
> On Mon, Feb 24, 2003 at 08:59:51PM +0100, Russell Coker wrote:
> > > gpm.te		General Purpose Mouse driver
> >
> > GPM is not suitable for core IMHO.  I've never used it or seen anyone use
> > it.
>
> Isn't gpm required by vim in Debian?

Apparently not.  The vim package does not require it, and I've used vim 
without using gpm before.  The vim package does require libgpmg1, but that 
doesn't require any SE policy.

> If it's installed per default,
> even if not used, the policy should be there.

The priority for gpm is "optional", while netkit-inetd is "important".  
Therefore I think that inetd policy should be in core and gpm shouldn't.

Also if you were to poll 100 admins as to what is a standard part of a Linux 
system, I expect that at least 90 would say inetd, while no more than 5 would 
say gpm.

> I use xfs-tt on my workstations, and you're correct, the main reason is
> anti-aliasing. Both machines work just fine without xfs.

Installing xfs policy won't be that difficult if you really need it.  Just as 
installing gpm policy won't b e difficult.

-- 
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: Core policy

[Tom]

On Tue, Feb 25, 2003 at 08:45:10AM +0100, Russell Coker wrote:
> Apparently not.  The vim package does not require it, and I've used vim 
> without using gpm before.  The vim package does require libgpmg1, but that 
> doesn't require any SE policy.

You and Brian are right, it's libgpm, not gpm itself.


> > I use xfs-tt on my workstations, and you're correct, the main reason is
> > anti-aliasing. Both machines work just fine without xfs.
> 
> Installing xfs policy won't be that difficult if you really need it.  Just as 
> installing gpm policy won't b e difficult.

I was trying to say: Leave it out, it's not important. Even if it's
installed and used, breaking it will not cause much trouble, only a few
apps won't look that crisp anymore and a few fonts won't work. Nothing
serious compared to, say, a failure to boot up correctly.


-- 
PGP/GPG key: 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.

Re: Core policy

[Jesse Pollard]

On Tuesday 25 February 2003 02:29 am, Tom wrote:
> On Tue, Feb 25, 2003 at 08:45:10AM +0100, Russell Coker wrote:
...
> > Installing xfs policy won't be that difficult if you really need it. 
> > Just as installing gpm policy won't b e difficult.
>
> I was trying to say: Leave it out, it's not important. Even if it's
> installed and used, breaking it will not cause much trouble, only a few
> apps won't look that crisp anymore and a few fonts won't work. Nothing
> serious compared to, say, a failure to boot up correctly.

On a side note: If the X server can access an xfs server on another system
you  may be importing data from a non-trusted host. This is just a reminder
if the X configuration designates an alternate font server host.

It is also entirely reasonable to use one font server for 10-20 workstations
since it doesn't  (at least not in my expierence) put that much of a load
on a system.

There has also been some effort to make use of xfs to provide fonts to
groff/ghostscript for rendering and printing. It has been a while since I
followed their development, so I don't know how far it has gone.
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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: Core policy

[Wayne Salamon]

On Mon, 24 Feb 2003, Russell Coker wrote:

> On Mon, 24 Feb 2003 19:55, Wayne Salamon wrote:
> > Here is a list of policy files that may considered the core policy.
> > However, this policy needs some work in order to build, but I'm trying to
> > get a feel for what users typically run on their systems.
>
> I think that you need to firstly define "core" more clearly.
>
> In previous discussions about core policy I always thought it was the packages
> needed for booting and for base functionality.  I don't think that such
> criteria matches your list of packages.
>
> > apache.te	Apache Web server; may need to be simplified to allow only
> > 		serving Web pages without CGI, etc.
>
> Most workstations do not need Apache.  The suggestion of separating out the
> CGI part is a good one.  I will investigate it.
>
> > apmd.te		Automatic Power Management daemon
> > cardmgr.te	PCMCIA control programs
>
> Perhaps we should have different groupings of policy?  apmd.te and cardmgr.te
> go together.  It's quite rare to use one without the other.
>
> > cups.te		Common Unix Printing System
> > lpr.te		Print client
>
> Do we need choices in the core policy?  Maybe we should make one the
> recommended option and the other the optional replacement.
>
> > dhcpc.te	DHCP client
> > pump.te		DHCP client
>
> I think that whatever pump needs should be merged into dhcpc.te.  There isn't
> that much a DHCP client can do, so there isn't a need to have two policy
> files IMHO.  Maybe a bit of ifdef in the policy for some of the less used
> features, but that's all.
>
> > gpm.te		General Purpose Mouse driver
>
> GPM is not suitable for core IMHO.  I've never used it or seen anyone use it.
>
> > portslave.te	Terminal server software (not sure about this one)
>
> Portslave is not needed for core policy.  The vast majority of Linux machines
> are not running as terminal servers.
>
> > procmail.te	Mail delivery agent for mail servers (may be removed)
>
> It's a server-only thing, IMHO it's claim is exactly as good as that of
> Apache.
>
> > rpcd.te		RPC daemon (not sure; how often do client workstations export
> > 		RPC services)
>
> Also using rpc without care is a huge security risk.  If you want a secure
> system then removing RPC is often a good thing to do.
>
> > X Windows potential core domains
> > ==================================================
> > xdm.te		X Display Manager
> > xfs.te		X font server
>
> xfs is not required IMHO.  I think that the only need for XFS is for TrueType
> fonts, and I get the impression that anti-aliasing benefits from this too.
> But the core functionality is fine without it.
>
> As for xdm, it currently doesn't work properly and has excessive permissions.
> I'm working on this now, I expect to have it sorted out in a couple of weeks
> along with a patch for kdm 3.1.
>
> > the policy source files. Also, there are several instances of rules being
> > duplicated in the generated policy due to macro usage.
>
> Duplication of rules is a minor annoyance, and I've been fixing it wherever I
> notice it.  But is it a big problem?  The compiler removes that anyway...
>
>

-- 
Wayne Salamon
wsalamon@tislabs.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: Core policy

[Leslie J. French]

There are probably as many definitions of "core" as there are people
actively working on SELinux.

I've put a SELinux box into a secured network that required that the box
pass a vulnerability/lockdown test.  Since the box acts as a server where
the only visible application is the one we put on it, my "core" is certainly
minimal!  It sounds similar to the other "hardened" systems people are
reporting.

The only "optional" component I have is sshd. I have no ftpd, telnetd, mail,
printing etc.  Since it took me a lot of trial-and-error to see which policy
files I could safely exclude, I certainly support the idea of a cleaner
hierarchy and a better notion of "linkage" between policies (try removing
crond and working backwards to clean up the errors).

However, for 95% of you (the other 19 active people?) I doubt if that
minimal a policy is any use.  Even so, I think that approach that the "core"
should only get the system booted is valid.  I'm thinking that "CPU+DISK"
makes a core. +NET makes a usable core, after that it's service-by-service
until you get to a full-blown installation running apache etc.

If "core" is the minimal system to get an experimenter up and running, then
it's already too big for me, but I managed to experiment with the "full" set
of policies.

So, does anyone have a list that might support only the "CPU+DISK" policy
list?

Leslie French
Semandex Networks Inc.




--
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: Core policy

[Clem Skorupka]

I believe a number of groups have taken this tact, and it's understood that the
example policy is just that: examples to be trimmed down or modified to suit your
particular security goals.
I also agree that a cleaner way to manage dependencies and untangle macros would be
useful.

My inclination is to define core policy along the lines of  "minimum needed so
system can boot/identify common devices, and be administrated" and not much more
than that.  And then add "core network" capabilities after that.

Basically think of core as the minimum services/policy that any stripped-down
"specialty" server would want.
So if I was building a hardened dns server, I would have no need of printing, or an
apache web server.  Or inetd/xinetd.
I wouldn't need sound.  Or dhcp client.

After that I'd create some category of "server" policy, to cover the webservers,
ftp servers, dns, et al.
Some might want to slice this up into internal servers (e.g. printing, databases)
vs. external servers (e.g. web).  I'd follow common industry practices such as
keeping servers "headless".

Another category would be "user-workstation/gui", which would include dhcp client,
x-windows, sound, web browsers.

Regards,

Clem Skorupka
The MITRE Corporation


Wayne Salamon wrote:

>   I would like some feedback from the list in order to begin paring back
> the SELinux example policy for a smaller 'core'. The idea is that other
> portions of the policy considered non-core will be in a directory whose
> files are not built into the core by default.
>
> Here is a list of policy files that may considered the core policy.
> However, this policy needs some work in order to build, but I'm trying to
> get a feel for what users typically run on their systems.
>
> The inclusion of a file should be determined by the needs of the system
> and what programs are expected to be run, and other needs of the system
> software (network interfaces, for example). The base platform is assumed
> to be a capable Linux workstation with few optional services.
>
> The X Windows related domains have been listed separately.
>
> domains/program (with corresponding file_contexts/program)
> ==========================================================
> apache.te       Apache Web server; may need to be simplified to allow only
>                 serving Web pages without CGI, etc.
> apmd.te         Automatic Power Management daemon
> atd.te          Atd server
> automount.te    Automount daemon
> bootloader.te   Lilo boot loader/manager
> cardmgr.te      PCMCIA control programs
> checkpolicy.te  SELinux policy compliler
> chkpwd.te       PAM password checking programs
> crond.te        Crond daemon
> crontab.te      Crontab manipulation programs
> cups.te         Common Unix Printing System
> devfsd.te       Control daemon for devfs device file system
> dhcpc.te        DHCP client
> fsadm           Disk and file system administration
> getty.te        Manage ttys
> gpm.te          General Purpose Mouse driver
> hotplug.te      Hardware event manager
> hwclock.te      Hardware clock manager
> ifconfig.te     Configure network interfaces
> inetd.te        Internet services daemon
> init.te         Process initialization
> initrc.te       System initialization scripts
> ipchains.te     IP packet filter administration
> klogd.te        Kernel log daemon
> ldconfig.te     Configure dynamic linker bindings
> load_policy.te  Policy loading utilities
> login.te        Local/remote login utilities
> logrotate.te    Rotate log files
> lpr.te          Print client
> modutil.te      Dynamic module utilities
> mount.te        Filesystem mount utilities
> netscape.te     Web browser (most of the policy is in a macros file)
> netutils.te     Network utilities (could be removed)
> newrole.te      SELinux utility to run a shell with a new role
> pamconsole.te   PAM console
> passwd.te       Password utilities
> ping.te         Send ICMP messages to network hosts
> portmap.te      Maintain RPC program number map
> portslave.te    Terminal server software (not sure about this one)
> pppd.te         PPP daemon
> procmail.te     Mail delivery agent for mail servers (may be removed)
> pump.te         DHCP client
> rlogind.te      Remote login daemon (can remove; shouldn't run rlogin anyway)
> rpcd.te         RPC daemon (not sure; how often do client workstations export
>                 RPC services)
> rpm.te          Red Hat package management
> rshd.te         RSH daemon (can remove; shouldn't run rsh anyway)
> selopt.te       SELinux ip labeling utilities (can be removed; should only
>                 be installed when experimenting with labeled packets)
> setfiles.te     SELinux filesystem labeling utilities
> sound.te        Sound utilities
> ssh.te          SSH daemon and ssh command
> su.te           Run shells with substitute user and group (most of the policy
>                 is contained in su_macros.te
> sxid.te         SUID/SGID program monitoring
> syslogd.te      System log daemon
> tmpreaper.te    Monitor and maintain temporary files
> usbmodules.te   List kernel modules for USB devices
> useradd.te      Manage system user accounts
> utempter.te     Privileged helper for utmp/wtmp updates
>
> X Windows potential core domains
> ==================================================
> xauth.te        X authority file utility
> xdm.te          X Display Manager
> xfs.te          X font server
> xserver.te      X Server
>
> Macros
> ======
> The use of macros has grown to be a large problem. The current policy makes use
> of macros that call other macros which call macros. Some macros should be
> eliminated; every_domain, every_test_domain for example. Others should be
> pared down to least privilege; the xx_file_perms and xx_dir_perms for example.
> The use of parameterized macros makes it very difficult to analyze the policy
> source files. Also, there are several instances of rules being duplicated
> in the generated policy due to macro usage.
>
> --
> Wayne Salamon
> wsalamon@tislabs.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.

--





--
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: Core policy

[Russell Coker]

On Mon, 24 Feb 2003 21:08, Clem Skorupka wrote:
> Basically think of core as the minimum services/policy that any
> stripped-down "specialty" server would want.
> So if I was building a hardened dns server, I would have no need of
> printing, or an apache web server.  Or inetd/xinetd.
> I wouldn't need sound.  Or dhcp client.

I agree with the concept, however I think that inetd may be considered a base 
package.  Also sshd should be there.

> After that I'd create some category of "server" policy, to cover the
> webservers, ftp servers, dns, et al.
> Some might want to slice this up into internal servers (e.g. printing,
> databases) vs. external servers (e.g. web).  I'd follow common industry
> practices such as keeping servers "headless".
>
> Another category would be "user-workstation/gui", which would include dhcp
> client, x-windows, sound, web browsers.

This concept makes a lot of sense to me.

I suggest that we make the second line of each .te file contain a comment 
stating which category it is in, with the possibility of policy being in 
multiple categories.

Also for serious distributions such as Red Hat and Debian we will eventually 
need a mapping between distribution package name and policy file.  If you 
install "kdm" or "gdm" on Debian then you need xdm.te.

-- 
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: Core policy

[Frank Mayer]

> I suggest that we make the second line of each .te file contain a
comment
> stating which category it is in, with the possibility of policy being
in
> multiple categories.

Category names are a good idea (e.g., #CATEGORY <category name> ).  I
can see all sorts of ways to use that in configuration tools.

I'd like to suggest that the third list be #DEPENDS <list of .te file
upon which this module depends> so we can also manage dependencies with
configuration tools.

Frank



--
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: Core policy

[Wayne Salamon]

On Mon, 24 Feb 2003, Frank Mayer wrote:

> Category names are a good idea (e.g., #CATEGORY <category name> ).  I
> can see all sorts of ways to use that in configuration tools.
>
> I'd like to suggest that the third list be #DEPENDS <list of .te file
> upon which this module depends> so we can also manage dependencies with
> configuration tools.
>

  I was thinking of something similar: a set of tags that can be used by
tools. Here's some I came up with:
#TITLE - The title, 30 characters or less (replaces the #DESC tag)
#DESCRIPTION (or #DESC) - Description, not limited in length

I also thought of a #DEPENDS tag, but I'm not sure how well it would be
maintained by the policy writers. What would be nice is to have some way
of annotating policy file relationships in a modular way; possibly an
#IMPORTS tag that means something to the compiler. If a policy file uses a
type defined in another file, unless that file is imported, it's an error.
The goal is to have more control over the relationships between policy
components.


 --
Wayne Salamon
wsalamon@tislabs.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: Core policy

[Frank Mayer]

> I also thought of a #DEPENDS tag, but I'm not sure how well it would
be
> maintained by the policy writers. What would be nice is to have some
way
> of annotating policy file relationships in a modular way; possibly an
> #IMPORTS tag that means something to the compiler. If a policy file
uses a
> type defined in another file, unless that file is imported, it's an
error.
> The goal is to have more control over the relationships between policy
> components.

I'm not sure what distinction you're trying to make between #DEPENDS and
#IMPORTS.  #DEPENDS as I suggest would list those modules upon which the
given module is dependent upon.  Much the same concept of #IMPORTS,
except #IMPORTS to me implies some type of compile time checking.  Since
compile here is primarily "cat" I would think we should use a less
active verb.  #USES also crossed my mind, but that's too weak.  It seems
"depends" is the correct verb, though I personally care less about the
verb we use than the semantics we imply with the verb.  I would be happy
if we just captured the dependencies for now and let tools evolve to
manage them.

I don't advocate doing anything to change how these files are
concatenated in the current make process; I think tools will eventually
evolve, and there will be many ways to build a valid policy.conf file
(editors, other make models, operational management infrastructure,
etc.).  Even if we change checkpolicy (which I do not advocate, that's
putting too much knowledge about one particular build process into the
native language compiler), I would still want other development tools to
check dependencies as I configure the policy to avoid the compile-time
errors. 

I do think the current macro model complicates this somewhat (some of
them have built-in dependencies too). 

Frank


--
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: Core policy

[Frank Mayer]

> #TITLE - The title, 30 characters or less (replaces the #DESC tag)
> #DESCRIPTION (or #DESC) - Description, not limited in length

While this is a reasonable suggestions, we for one already have released
tools that assumes a semantic for #DESC.  By changing that, you put us
in a position of changing the tool (easy) while remaining backwards
compatible with older policies that other still use (very difficult if
you redefine a given tag).  At a minimum I would ask that you leave
#DESC and #TITLE as synonyms to aid with maintaining backwards
compatibility.  Really I would prefer if we just keep with the #DESC as
the short description (or title) tag.

In any event if #DESC is being changed in the next release please give
us some warning so we can update sepcut and test it, and try to figure
out some type backwards compatibility scheme.

Frank


--
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: Core policy

[Russell Coker]

On Tue, 25 Feb 2003 12:35, Wayne Salamon wrote:
> I also thought of a #DEPENDS tag, but I'm not sure how well it would be
> maintained by the policy writers. What would be nice is to have some way
> of annotating policy file relationships in a modular way; possibly an
> #IMPORTS tag that means something to the compiler. If a policy file uses a
> type defined in another file, unless that file is imported, it's an error.
> The goal is to have more control over the relationships between policy
> components.

Surely #IMPORTS or #DEPENDS would work equally well.

As for raising an error, it should be either treated as a warning, an error, 
or ignored depending on command line options.  I think that most people won't 
want to maintain such things when they modify their own policy files.

-- 
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: Core policy

[Dale Amon]

On Mon, Feb 24, 2003 at 10:12:20PM +0100, Russell Coker wrote:
> On Mon, 24 Feb 2003 21:08, Clem Skorupka wrote:
> > Basically think of core as the minimum services/policy that any
> > stripped-down "specialty" server would want.
> > So if I was building a hardened dns server, I would have no need of
> > printing, or an apache web server.  Or inetd/xinetd.
> > I wouldn't need sound.  Or dhcp client.

This sort of thing crossed my mind as well. More applicable
to Russell than others because of the Debian Way... but
perhaps map policy sets so they work nicely with
Debian tasksel, particularly for the default dselect
categories when you boot up a newly installed system for
the first time.

-- 
------------------------------------------------------
       IN MY NAME:            Dale Amon, CEO/MD
  No Mushroom clouds over     Islandone Society
    London and New York.      www.islandone.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.

Re: Core policy

[Wayne Salamon]

On Mon, 24 Feb 2003, Clem Skorupka wrote:

> Basically think of core as the minimum services/policy that any stripped-down
> "specialty" server would want.

  We're trying to define 'core' as what a SELinux experimenter needs to
get up and running. I'd say basic workstation functionality, sshd, the
policy tools, but not X Windows.

> So if I was building a hardened dns server, I would have no need of printing, or an
> apache web server.  Or inetd/xinetd.
> I wouldn't need sound.  Or dhcp client.
>

  I've done that for another project. A hardened server (a comm router)
that doesn't even allow remote administration. Policy can be very small.
That larger challenge is integrating SELinux policy with other policies
that affect the operation of the server.

> After that I'd create some category of "server" policy, to cover the webservers,
> ftp servers, dns, et al.
> Some might want to slice this up into internal servers (e.g. printing, databases)
> vs. external servers (e.g. web).  I'd follow common industry practices such as
> keeping servers "headless".
>
> Another category would be "user-workstation/gui", which would include dhcp client,
> x-windows, sound, web browsers.
>

  I don't mind the ideas of categories, but how do we want to distribute
such things as part of the SELinux distribution? Is it a build option
('make workstation'), is it a set of guidelines? Suggestions?

  For now, though, the focus is on defining the core as described above,
then cleaning up this policy to provide least privilege, removing some
macros, cleaning up the dependencies between policy files, etc.

Thanks for the suggestions.

 --
Wayne Salamon
wsalamon@tislabs.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: Core policy

[Westerman, Mark]

I agree with Wayne, 
There needs some real work done on policy managemnet. 
Core policy and addons seem to be a good idea.

>Macros
>======
> The use of macros has grown to be a large problem. 
> ......
> The use of parameterized macros makes it very difficult to analyze the
policy
> source files. Also, there are several instances of rules being duplicated
> in the generated policy due to macro usage.

In tring to run conversions on the policy file to xml I run into problem
with the macro usage. 


Mark Westerman

--
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: Core policy

[Stephen D. Smalley]

Wayne Salamon wrote:
> The use of macros has grown to be a large problem. The current policy makes 
use
> of macros that call other macros which call macros. Some macros should be
> eliminated; every_domain, every_test_domain for example. Others should be
> pared down to least privilege; the xx_file_perms and xx_dir_perms for example.
> The use of parameterized macros makes it very difficult to analyze the policy
> source files. Also, there are several instances of rules being duplicated
> in the generated policy due to macro usage.

In addition to the problem of overly permissive macros, there are also
a number of problems caused by the use of type attributes such as
'domain' and 'file_type' (as well as the other attributes like pidfile)
in allow rules.  Although there are legitimate cases where this is
appropriate (e.g. allowing init to kill all processes, allowing
setfiles to relabel all files), there is a tendency to misuse type
attributes that map to a very large set of domains/types in allow rules
that should only be applied to a more specific set.  This prevents
people from creating new domains or types that are rigorously isolated
from the rest of the system (unless they omit these attributes from
those domains or types, which then requires them to explicitly
enumerate the legitimate cases that are normally handled by those
attributes and causes problems with assertions that expect those
attributes to include certain functional classes of types).  It would
be helpful to audit the existing macros and domains for such rules and
to consider how we can refine them, e.g. defining new attributes for
more specific sets, explicitly enumerating the sets in certain cases,
eliminating the rule entirely if it isn't truly necessary.

With regard to macros, I think that they are helpful when they provide
a useful abstraction and are carefully limited to that abstraction
(i.e. no granting of permissions only weakly related to that
abstraction).  For example, domain_auto_trans and file_type_auto_trans
provide useful abstractions of the higher level concepts of domain
transitions and file type transitions, although we should audit them to
ensure that they are not being overly permissive.  They would actually
have been incorporated into the base language as primitives except for
the fact that there is some potential variance in the specific set of
permissions that you may want to grant in certain cases (the macros
merely express the common case).  In contrast, every_domain does not
provide any useful abstraction and merely conceals many permissions.
Some of its finer-grained macros might be ok (e.g.
general_domain_access) while others need to be split up further or
eliminated entirely.  Likewise, can_exec_any should likely be
eliminated entirely.

--
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: Core policy

[Wayne Salamon]

On Tue, 25 Feb 2003, Stephen D. Smalley wrote:

>
> With regard to macros, I think that they are helpful when they provide
> a useful abstraction and are carefully limited to that abstraction
> (i.e. no granting of permissions only weakly related to that
> abstraction).  For example, domain_auto_trans and file_type_auto_trans
> provide useful abstractions of the higher level concepts of domain
> transitions and file type transitions, although we should audit them to
> ensure that they are not being overly permissive.

  I agree with the above. The macros that I was (mostly) referring to are
the ones in macros/program. The idea behind these seems to have
parameterized domain/type definitions. I'm not convinced they're a good
idea, and many have dependencies to types defined in other .te files.


 --
Wayne Salamon
wsalamon@tislabs.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: Core policy

[Russell Coker]

On Tue, 25 Feb 2003 16:41, Stephen D. Smalley wrote:
> merely express the common case).  In contrast, every_domain does not
> provide any useful abstraction and merely conceals many permissions.
> Some of its finer-grained macros might be ok (e.g.
> general_domain_access) while others need to be split up further or
> eliminated entirely.  Likewise, can_exec_any should likely be
> eliminated entirely.

I think that the reason that not much has been done on this issue is that the 
macros in question have to be removed from the main tree.

Once those macros get removed from the main tree I'll copy the change into my 
tree and start work on fixing whatever breaks (and I'm sure that other people 
will do the same).

While things are working moderately well I'm not in a hurry to make such 
changes on my own.

-- 
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: Core policy

[Stephen D. Smalley]

Russell Coker wrote:
> I suggest that we make the second line of each .te file contain a comment 
> stating which category it is in, with the possibility of policy being in 
> multiple categories.

While this seems reasonable to me, I'd suggest that we first identify
the core policy components, cleanly separate out the non-core
components, and perform a thorough audit and reduction of the core
macros and domains.  Then, we can incrementally work on a similar audit
and reduction of each of the non-core policy components, including
categorizing them and determining their interdependencies.

--
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: Core policy

[Stephen D. Smalley]

Wayne Salamon wrote:
>   I agree with the above. The macros that I was (mostly) referring to are
> the ones in macros/program. The idea behind these seems to have
> parameterized domain/type definitions. I'm not convinced they're a good
> idea, and many have dependencies to types defined in other .te files.

Creating derived domains (and associated derived types) from the
calling domain is actually good practice, as it allows you to maintain
separation between the user domains.  Otherwise, you end up with an
initial separation between the user domains that can be easily
circumvented through shared program domains that have the same accesses
to the same types.  I'd agree that all of the macros (including the
global macros as well as the program macros) need a thorough audit and
reduction, but I don't think you truly want to eliminate the use of
program macros for instantiating program domains.

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