broad domains

broad domains

[Robert Bihlmeyer]

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

Hi,

I started work on a generic X client domain, but now I get the feeling
that this may not be the right way to go. As I have to add this
permission for this client, and that permission for that program, the
domain gets quite broad. Maybe these generic domains are a mistake?

A have the same problem with the games domain provided in the default
policy (or at least in Russell's package). As is, it doesn't fit half
the stuff in my /usr/games.

On the other hand, having a domain for every teensy toy out there
seems a bit excessive.

Any advice?



BTW, can't setfiles assume some default user & role if none is given?
Repeating system_u:object_r: a million times is superflous.

-- 
Robbe

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: broad domains

[Stephen Smalley]

On Sun, 2003-04-20 at 03:11, Robert Bihlmeyer wrote:
> On the other hand, having a domain for every teensy toy out there
> seems a bit excessive.

There isn't any point in defining a separate domain unless you need to
control/protect the program differently.  You need to decide what your
security goals are, identify what resources need to be protected, and
what processes need to be separated.

> BTW, can't setfiles assume some default user & role if none is given?
> Repeating system_u:object_r: a million times is superflous.

This has come up previously on the list; we prefer that the applications
not assume anything about the internal structure of a security context,
so that they will continue to work if you add or remove security models
to/from the policy engine.  SELinux was designed to provide policy
flexibility and minimize the need for policy-specific code outside of
the policy engine.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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] broad domains

[Magosányi Árpád]

Hi!

Although I work with RSBACs RC modell, maybe my experiences could be of
use for you also.

To be able to understand what might of concern to you, a short explanation
of the model I have implemented:
The TCB have the standard roles and types (sort of), with generic,
secadm and sysadm roles. I also have a type for tty devices and a
type for "logging", which is write-only for most.
The userspace is in a chrooted environment, where I have system,
public, confidential, secret/{work} and secret/{private} roles,
and the types corresponding to them. The MAC policy is something
resembling to Bell&LaPadula.
I have a special domain for the X server to allow it to mmap, and for
or five additional file related extras (AUTH_MAY_SETUID flag in
sudo, login and su, RC role dependant symlinks for /tmp and /home, and
it is nearly everything).

I use gnome.


Zeroth, no x client have setuid bit. They just do not need it, and
they are too big to have one.

First, most of the X clients need nothing special. Actually I do not
have any special domain for them. For a more fine-grained modell,
you would need extra access to wtmp and tty files for xterm and
such thingies, but it is not because they are x programs, but because
they are hmm... use login mechanisms.

The obvius thing to set for X clients is the right to access the
X server. As it runs in another domain (and because for a while it seemed
that it will run as part of the TCB), I chose to use tcp transport.

Another thing to consider is xdm and such things. I do not (yet?)
use xdm:) I guess it will need a new role.

Another thing is the question of handling of MIT cookies.
I use static keys (yet), and I regard this problem to be either
related to xdm or (as?) the implementation of a correct trusted
mechanism for key distribution for X sessions.

Another thing is the MITSHM extension. My clients cannot actually
use it due to a rsbac problem related to the initial type of the
created IPC objects, but if it would work fine, this could be set
up by modifying the X server role. Anyway, libs are smart enough to
live without mitshm.

Another thing is the Ice extension, gnome config daemon and such.
I see that these machanisms are working in a statisfactory (for me)
level, which means that the instances in different levels do not
interfere much because the namespace separation of the user
writeable directories, and I cannot see any functional problem
worth mentioning. I can even run different openoffice.org
instances for each domain, and even cannot cut&paste between
them, because they use a mechanisms above the standard X one
which is domain separated.

The main problem area for me is the separation of domains in use
of the X server mechanisms (think cut&paste), and the visualisation
of the different security levels. Reading some X documentation
it became clear that the neded security functions cannot and should
not be implemented using some existing mechanisms of the X server
(it cannot tell you authentication info or security attributes about
the owner of a window), or some new server extensions (to have security
infrastructure within the X server, it should have been completely
rewritten). But the X protocol is a point where these mechanisms should
and can be handled in an assured way. So I figured out that I should
write a X proxy as the core component of X security, but don't hold
your breath.



A levelezőm azt hiszi, hogy Robert Bihlmeyer a következőeket írta:
> Hi,
> 
> I started work on a generic X client domain, but now I get the feeling
> that this may not be the right way to go. As I have to add this
> permission for this client, and that permission for that program, the
> domain gets quite broad. Maybe these generic domains are a mistake?
> 
> A have the same problem with the games domain provided in the default
> policy (or at least in Russell's package). As is, it doesn't fit half
> the stuff in my /usr/games.
> 
> On the other hand, having a domain for every teensy toy out there
> seems a bit excessive.
> 
> Any advice?
> 
> 
> 
> BTW, can't setfiles assume some default user & role if none is given?
> Repeating system_u:object_r: a million times is superflous.
> 
> -- 
> Robbe



-- 
GNU GPL: csak tiszta forrásból


--
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: broad domains

[Russell Coker]

On Sun, 20 Apr 2003 17:11, Robert Bihlmeyer wrote:
> I started work on a generic X client domain, but now I get the feeling
> that this may not be the right way to go. As I have to add this
> permission for this client, and that permission for that program, the
> domain gets quite broad. Maybe these generic domains are a mistake?

Which generic domains are you referring to?

Why do you want to add a special domain for X clients?

For good X security we need something like Cluster Mode Workstation 
http://www.ornl.gov/~jar/cmw4me.pdf .  Many people have been talking about 
writing an X proxy or modifying the X server and/or window manager for such 
things.  But nothing has been done yet.

> A have the same problem with the games domain provided in the default
> policy (or at least in Russell's package). As is, it doesn't fit half
> the stuff in my /usr/games.

How does it not fit them?

> On the other hand, having a domain for every teensy toy out there
> seems a bit excessive.

Yes, it becomes a management nightmare which isn't good for security.

> BTW, can't setfiles assume some default user & role if none is given?
> Repeating system_u:object_r: a million times is superflous.

I did that once and Steve convinced me to stop doing it.

-- 
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: broad domains

[Robert Bihlmeyer]

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

Russell Coker <russell@coker.com.au> writes:

> On Sun, 20 Apr 2003 17:11, Robert Bihlmeyer wrote:
> > [...] Maybe these generic domains are a mistake?
> 
> Which generic domains are you referring to?

My X client domain, the games domain from the default policy.

> Why do you want to add a special domain for X clients?

I wanted to avoid giving user_t direct access to the X server or the
DRI devices. But since I now think that this was mistaken, I now grant
normal Xlib-style access to user_t, and open special domains for the
programs that need DRI.

> For good X security we need something like Cluster Mode Workstation 
> http://www.ornl.gov/~jar/cmw4me.pdf .




> > A have the same problem with the games domain provided in the default
> > policy (or at least in Russell's package). As is, it doesn't fit half
> > the stuff in my /usr/games.
> 
> How does it not fit them?

I simply don't think it makes sense to put a class as diverse as games
into one domain. Some games, need X access (provided by the default
policy), some none. Some need direct video access, or want to output
(in rare cases input) sound. Some need read access to game data, or
r/w access to state (hiscore, save games), that may be located in a
shared area or in a fixed or variable location below the user's home. 
Sometimes even the game data or the game itself is in a user-specified
location (think: Doom WADs or Infocom zcode).

Basically, I think most games should just run under user_t, and the
blanket specification putting everything in /usr/games into this
domain is wrong.

> > On the other hand, having a domain for every teensy toy out there
> > seems a bit excessive.
> 
> Yes, it becomes a management nightmare which isn't good for security.

If we had a stronger inheritance model (maybe just through m4 macros)
I'm not so sure it's too hard to handle.

> > BTW, can't setfiles assume some default user & role if none is given?
> > Repeating system_u:object_r: a million times is superflous.
> 
> I did that once and Steve convinced me to stop doing it.

Any subject keywords or URL so I can find the arguments?

-- 
Robbe

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: broad domains

[Russell Coker]

On Mon, 28 Apr 2003 02:17, Robert Bihlmeyer wrote:
> > > A have the same problem with the games domain provided in the default
> > > policy (or at least in Russell's package). As is, it doesn't fit half
> > > the stuff in my /usr/games.
> >
> > How does it not fit them?
>
> I simply don't think it makes sense to put a class as diverse as games
> into one domain. Some games, need X access (provided by the default
> policy), some none. Some need direct video access, or want to output

The problem is in categorising the games.  There are a huge number of games, 
they are being written and re-written all the time.  For something that's 
easy to setup having a single domain for all of them works reasonably well.

> (in rare cases input) sound. Some need read access to game data, or
> r/w access to state (hiscore, save games), that may be located in a
> shared area or in a fixed or variable location below the user's home.
> Sometimes even the game data or the game itself is in a user-specified
> location (think: Doom WADs or Infocom zcode).

I think that my policy covers this reasonably well.

> Basically, I think most games should just run under user_t, and the
> blanket specification putting everything in /usr/games into this
> domain is wrong.

So if you run a network game that is compromised then it can run "ssh host" 
and use your ssh authorized key.  It can ptrace other processes that you run, 
send all your files out over the network, and do every other bad thing you 
can imagine.

Of course with the current situation regarding X a cracked game could sniff 
the keyboard when you are entering a password.  But this is more difficult to 
arrange, and we do plan to solve the X problem eventually.

If you want games to run in user_t then simply don't install games.te.

> > > On the other hand, having a domain for every teensy toy out there
> > > seems a bit excessive.
> >
> > Yes, it becomes a management nightmare which isn't good for security.
>
> If we had a stronger inheritance model (maybe just through m4 macros)
> I'm not so sure it's too hard to handle.

Go for it.  Write some sample policy and demonstrate to us how easy it is!

> > > BTW, can't setfiles assume some default user & role if none is given?
> > > Repeating system_u:object_r: a million times is superflous.
> >
> > I did that once and Steve convinced me to stop doing it.
>
> Any subject keywords or URL so I can find the arguments?

Just search the mailing list archives for devfsd, I think the early discussion 
of the devfsd module contains the relevant information.

-- 
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: broad domains

[Brian May]

On Mon, Apr 28, 2003 at 03:14:59AM +1000, Russell Coker wrote:
> The problem is in categorising the games.  There are a huge number of games, 
> they are being written and re-written all the time.  For something that's 
> easy to setup having a single domain for all of them works reasonably well.

Why not just something like:

uses_network(thegame)
uses_tty(thegame)
uses_x_window(thegame)
rw_game_scores(thegame)

(not crossreferenced at all with existing policy)

Atually this raises an issue I have been thinking of lately,
I am not sure I like the uses_network (or whatever it was
called).

Typically a game may need to:

- bind to specific TCP port.
  Receive connections to this TCP port.
  Send/receive data on this TCP port.

- bind to specific UDP port.
  Send/receive data on this UDP port.

- send/receive TCP/UDP data on domain port to DNS server listed in
  /etc/resolv.conf.

But an attacker could also do other stuff that the game doesn't need to
do. Like:

- connect to a computer inside a private network with a port like 137,
139, or another one that is denied access at the firewall, and try to
attack it.

- connect to SMTP port of random computers on outside (or inside)
network and send lots of SPAM. At least some computers inside network
will probably act at relays to the outside world, making it clear where
the SPAM came from...

- act as a relay and relay private DNS domains to an attacker on the
outside world (this in particular may be a problem to fix).

I am not sure if it is possible to solve these issue.

Obviously there is also the issue that it would be silly to run such
a public game on the same network you want to keep secure (it would
probably be better to put it on its own network with a firewall that
disallows outgoing connections for instance), here I am looking for a
potential SE-Linux solution rather then a solution envolving redesign of
the network.
-- 
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.