setting up new test user domain?

setting up new test user domain?

[lonnie]

Hello All,

Since I am very new to SELinux, I hope that all of you will forgive the many 
dumb questions that I will probably end up asking.

Instead of modifying the user.te and every.te for our project, I think that it 
might be better if I simple create a new test domain and place a "test" user in 
that domain.

>From what I can understand so far, if the user does not belong to a particular 
domain then they will not have access it. 

With this in mind then if I add a user to a newly developed domain for that 
particular user and also have their HOME directory as a member if the single 
user domain then I could effectively prevent them from moving out of 
the /home/test into the /home or any other directory.

Would this be correct? If so then couls someone please help me to figure out 
how to set up a simple domain from which to begin this process?

Also, I have made a subdirectory in the selinux/domains directory because I 
have seen this in the make file as well and this will make it so that I do not 
have to modify the makefile.

All Help would be greatly appreciated,
Lonnie


--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Since I would like to modify the original files as little a possible then it 
sounds to me like Option 1 would be be the best direction and I can usr the 
user_t (user.te) as a template for this new user domain.

Now then, after making the new domain, should I presume that I can simply use 
the standard "adduser" to put a user in that domain, and also use the 
standard "chown" to change the ownership of files to belong to the new domain?

Cheers,
Lonnie

Quoting Stephen Smalley <sds@tislabs.com>:

> 
> On Tue, 18 Dec 2001 lonnie@outstep.com wrote:
> 
> > Instead of modifying the user.te and every.te for our project, I think
> that it
> > might be better if I simple create a new test domain and place a
> "test" user in
> > that domain.
> 
> The rules in every.te are applied to every domain (or, to be more
> specific, to every type with the "domain" type attribute).  So if you
> create a test domain, these rules will also be applied to it unless
> you
> either 1) omit the "domain" type attribute from its declaration or 2)
> change every.te to exclude your test domain.
> 
> Option #1 will violate one of the assertions in the example policy, so
> you
> will have to remove that assertion from assert.te if you follow that
> route.  It will also require some additional rules for your test
> domain
> that are normally automatically picked up using the "domain"
> attribute,
> e.g. allowing init and the system administrator to kill the domain.
> 
> Option #2 requires you to edit every.te, but allows you to leave the
> assertions alone and lets you pick up the other rules automatically.
> If you name your new domain "testdomain", then you can do something
> like:
> 	sed "s/domain/~testdomain/g" every.te > newevery.te
> 	mv newevery.te every.te
> to create an every.te file that excludes your test domain.
> 
> > Would this be correct? If so then couls someone please help me to
> figure out
> > how to set up a simple domain from which to begin this process?
> 
> There are plenty of examples of domains in the current policy; use one
> of
> them as a starting point.  The most obvious one is the user_t domain
> that
> is currently used for ordinary users.  This is defined in
> domains/user/user.te.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Tue, 18 Dec 2001 lonnie@outstep.com wrote:

> Instead of modifying the user.te and every.te for our project, I think that it
> might be better if I simple create a new test domain and place a "test" user in
> that domain.

The rules in every.te are applied to every domain (or, to be more
specific, to every type with the "domain" type attribute).  So if you
create a test domain, these rules will also be applied to it unless you
either 1) omit the "domain" type attribute from its declaration or 2)
change every.te to exclude your test domain.

Option #1 will violate one of the assertions in the example policy, so you
will have to remove that assertion from assert.te if you follow that
route.  It will also require some additional rules for your test domain
that are normally automatically picked up using the "domain" attribute,
e.g. allowing init and the system administrator to kill the domain.

Option #2 requires you to edit every.te, but allows you to leave the
assertions alone and lets you pick up the other rules automatically.
If you name your new domain "testdomain", then you can do something like:
	sed "s/domain/~testdomain/g" every.te > newevery.te
	mv newevery.te every.te
to create an every.te file that excludes your test domain.

> Would this be correct? If so then couls someone please help me to figure out
> how to set up a simple domain from which to begin this process?

There are plenty of examples of domains in the current policy; use one of
them as a starting point.  The most obvious one is the user_t domain that
is currently used for ordinary users.  This is defined in
domains/user/user.te.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Tue, 18 Dec 2001 lonnie@outstep.com wrote:

> Now then, after making the new domain, should I presume that I can simply use
> the standard "adduser" to put a user in that domain, and also use the
> standard "chown" to change the ownership of files to belong to the new domain?

No.  adduser hasn't been modified to be aware of SELinux, and chown only
deals with the Linux user and group attributes.  You need to define an
entry for the new user and his authorized roles in policy/users and an
entry for the new role and its authorized domain(s) in policy/rbac.  To
set the security context on the user's home directory, you can use the
new 'chcon' program.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Well, I actually have opted to go with Option #2 and have:

1. made a directory domains/test
2. cp domains/users/users.te ../test/testuser.te
3. sed "s/domain/~test_user/g" every.te newevery.te
   mv newevery.te every.te

I should now go and add "test_user_r" to the rbac and then modify the 
testuser.te to reflect test_user_t

I think that these are the correct steps?

Also, is there a small tutorial on doing some of these basic things?

Best Regards,
Lonnie

Quoting Stephen Smalley <sds@tislabs.com>:

> 
> On Tue, 18 Dec 2001 lonnie@outstep.com wrote:
> 
> > Now then, after making the new domain, should I presume that I can
> simply use
> > the standard "adduser" to put a user in that domain, and also use
> the
> > standard "chown" to change the ownership of files to belong to the new
> domain?
> 
> No.  adduser hasn't been modified to be aware of SELinux, and chown
> only
> deals with the Linux user and group attributes.  You need to define an
> entry for the new user and his authorized roles in policy/users and an
> entry for the new role and its authorized domain(s) in policy/rbac. 
> To
> set the security context on the user's home directory, you can use the
> new 'chcon' program.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Hi there,

I have made a copy of the user.te to be_user.te and have changes all instances 
of "user" ti "be_user" and changed the "domain" to "be_domain" inside 
be_user.te.

I have also added the be_user_r definition to the rbac file.

The las t thing that I have done was to "sed "s/domain/~be_domain/g" every.te > 
newevery.te and then copy it over.

the problem that I am getting now is an assertion error:

assertion fail: allow be_user_su_t be_user_t:process { transition } was granted

could you please tell me what these assertion errors mean and, in general, how 
to fix them?

Cheers,
Lonnie

Quoting Stephen Smalley <sds@tislabs.com>:

> 
> On Tue, 18 Dec 2001 lonnie@outstep.com wrote:
> 
> > Now then, after making the new domain, should I presume that I can
> simply use
> > the standard "adduser" to put a user in that domain, and also use
> the
> > standard "chown" to change the ownership of files to belong to the new
> domain?
> 
> No.  adduser hasn't been modified to be aware of SELinux, and chown
> only
> deals with the Linux user and group attributes.  You need to define an
> entry for the new user and his authorized roles in policy/users and an
> entry for the new role and its authorized domain(s) in policy/rbac. 
> To
> set the security context on the user's home directory, you can use the
> new 'chcon' program.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux
> 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.
> 

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Wed, 19 Dec 2001 lonnie@outstep.com wrote:

> I have made a copy of the user.te to be_user.te and have changes all instances
> of "user" ti "be_user" and changed the "domain" to "be_domain" inside
> be_user.te.

You should leave the "domain" type attribute unchanged.  Since you are
changing every.te, you can leave this attribute unmodified.  You only need
to modify the domain attribute if you aren't changing every.te.  As I
mentioned earlier, if you change the attribute, you have to remove an
assertion to avoid the error you are encountering.

> the problem that I am getting now is an assertion error:
>
> assertion fail: allow be_user_su_t be_user_t:process { transition } was granted
>
> could you please tell me what these assertion errors mean and, in general, how
> to fix them?

In this case, you just need to restore the "domain" type attribute for
your new domain.  This assertion is the first one in the assert.te file,
and it verifies that every type that can be associated with a process is
also tagged as a domain.

If you haven't already done so, you might want to read the Policy
Configuration Language description from the first technical report
skim the second technical report, and read the "Meeting Critical Security
Objectives..." published paper available from
http://www.nsa.gov/selinux/docs.html.  These reports and papers provide
quite a bit of information, but it is admittedly difficult to get started.
We plan on writing a new policy document that is better suited for people
who want to customize their policy, define new roles, domains and/or
types, or even create a new policy from scratch, but this will take some
time.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Gary Lowder]

Lonnie,

I hate to completely change the direction you're headed but...
Based on what you've said earlier about what you want to accomplish, it 
seems a chroot jail is what you want for your users.  Why reinvent the 
wheel?  Of course you can beat SELinux into doing what you're asking, 
but that's not really what it was designed to directly accomplish.

Largo, Florida, implemented a linux system for it's municipality workers 
to use.  A base link off of which you might find lots of useful 
information is:  http://www.consultingtimes.com/Largo.html
He didn't do exactly what you're talking about, but it's not far off.

Where I would actually start, is a site to help explain and set up a 
chroot jail, one of I'm sure many sites is: 
http://www.gsyc.inf.uc3m.es/~assman/jail/1.html

I'm sure there are others out there.

With a large enough hammer it is entirely possible to beat a square peg 
into a round hole, but it's much easier to just find the round peg.

Hope this helps you accomplish your objectives.

Gary.



--
You have received this message because you are subscribed to the selinux 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.

Debian SE Linux ?

[Noah silva]

Hello,

looking back on the list, I saw some people have discussed using Debian
Linux with the SELinux patch.  I was wondering if that ever came to
anything other than talk.  I am currently working on setting up a test
machine with Debian Testing (on x86) and SE Linux.  (ATM, I am still
sorting out ext3 + initrd... can't believe there isn't a cleaner
solution).

Looking at the way SELinux works, I assume I will have at least to alter
the policies because of the differences in paths?

 -- noah silva 



--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Actually I found out that I had to use the original unchanged every.te as well 
as changing the be_domain back to domain in the be_user.te file.

My next questions will then be on how to use this new domain and create a new 
user with it's attributes. After that is done then I will try to edit the 
be_user.te file and try to start turning off things until I can effectively 
keep the user in their directory.

Would this be a proper methodology for this task?

cheers,
Lonnie

Quoting Stephen Smalley <sds@tislabs.com>:

> 
> On Wed, 19 Dec 2001 lonnie@outstep.com wrote:
> 
> > I have made a copy of the user.te to be_user.te and have changes all
> instances
> > of "user" ti "be_user" and changed the "domain" to "be_domain"
> inside
> > be_user.te.
> 
> You should leave the "domain" type attribute unchanged.  Since you are
> changing every.te, you can leave this attribute unmodified.  You only
> need
> to modify the domain attribute if you aren't changing every.te.  As I
> mentioned earlier, if you change the attribute, you have to remove an
> assertion to avoid the error you are encountering.
> 
> > the problem that I am getting now is an assertion error:
> >
> > assertion fail: allow be_user_su_t be_user_t:process { transition }
> was granted
> >
> > could you please tell me what these assertion errors mean and, in
> general, how
> > to fix them?
> 
> In this case, you just need to restore the "domain" type attribute for
> your new domain.  This assertion is the first one in the assert.te
> file,
> and it verifies that every type that can be associated with a process
> is
> also tagged as a domain.
> 
> If you haven't already done so, you might want to read the Policy
> Configuration Language description from the first technical report
> skim the second technical report, and read the "Meeting Critical
> Security
> Objectives..." published paper available from
> http://www.nsa.gov/selinux/docs.html.  These reports and papers
> provide
> quite a bit of information, but it is admittedly difficult to get
> started.
> We plan on writing a new policy document that is better suited for
> people
> who want to customize their policy, define new roles, domains and/or
> types, or even create a new policy from scratch, but this will take
> some
> time.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux
> 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.
> 

--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Stephen Smalley]

> looking back on the list, I saw some people have discussed using Debian
> Linux with the SELinux patch.  I was wondering if that ever came to
> anything other than talk.  I am currently working on setting up a test
> machine with Debian Testing (on x86) and SE Linux.  (ATM, I am still
> sorting out ext3 + initrd... can't believe there isn't a cleaner
> solution).

Russell Coker has a Debian kernel-patch package for SELinux at
http://www.coker.com.au/selinux.  I don't know whether the Debian folks
have made any progress with the daemon and utility patches or the example
policy configuration.  I'm not sure what you mean when you say
"I am still sorting out ext3 + initrd."  The current release of SELinux
works fine with ext3 - we were just waiting for ext3 to be merged into the
mainstream kernel, and it is present in the 2.4.16 kernel.  As far as
initrd is concerned, you can probably make it work if you really need it.
I think you just need to create an initrd image that includes a copy of the
compiled policy configuration so that it is available.

> Looking at the way SELinux works, I assume I will have at least to alter
> the policies because of the differences in paths?

You will need to adapt the daemon and utility patches to the corresponding
Debian packages, although only a few of these patches are critical (login,
sshd, crond).  You will have to customize setfiles/file_contexts for your
filesystem layout.  If you build with NSA SELinux Development Module
option, then you can run your system in permissive mode for a while to
collect audit messages, and can then work on customizing the policy
configuration based on those audit messages, possibly using Justin Smith's
perl script.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Flood Randy Capt AFCA/TCAA]

But, under certain circumstances, chrooted jails can be broken out of.
Right?  

For example, see:

http://www.bpfh.net/simes/computing/chroot-break.html

Is this information dated?  Is chroot really more reliable now?  Isn't
the whole concept of type enforcement to give an additional layer of
security in such cases?  



-----Original Message-----
From: Gary Lowder [mailto:gary@lowder.com]
Sent: Wednesday, December 19, 2001 11:56 AM
To: SELinux@tycho.nsa.gov
Subject: Re: setting up new test user domain?


Lonnie,

I hate to completely change the direction you're headed but...
Based on what you've said earlier about what you want to accomplish, it 
seems a chroot jail is what you want for your users.  Why reinvent the 
wheel?  Of course you can beat SELinux into doing what you're asking, 
but that's not really what it was designed to directly accomplish.

Largo, Florida, implemented a linux system for it's municipality workers

to use.  A base link off of which you might find lots of useful 
information is:  http://www.consultingtimes.com/Largo.html
He didn't do exactly what you're talking about, but it's not far off.

Where I would actually start, is a site to help explain and set up a 
chroot jail, one of I'm sure many sites is: 
http://www.gsyc.inf.uc3m.es/~assman/jail/1.html

I'm sure there are others out there.

With a large enough hammer it is entirely possible to beat a square peg 
into a round hole, but it's much easier to just find the round peg.

Hope this helps you accomplish your objectives.

Gary.



--
You have received this message because you are subscribed to the selinux
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.

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Wed, 19 Dec 2001 lonnie@outstep.com wrote:

> Actually I found out that I had to use the original unchanged every.te as well
> as changing the be_domain back to domain in the be_user.te file.

No, that isn't right.  If you use the original every.te file and you keep
the "domain" attribute on your new domain, then the rules in every.te will
be applied to your new domain, which is more permissive than you want.  As
I said originally, you must either change every.te to exclude your new
domain or you must not use the "domain" attribute on your new domain.  The
first option seems preferable (changing every.te).

Please make sure that you've read the available documentation regarding
the policy before proceeding any further.  Randomly making changes without
any understanding of what you are doing is unlikely to produce the desired
result.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com






--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Wed, 19 Dec 2001, Gary Lowder wrote:

> I hate to completely change the direction you're headed but...
> Based on what you've said earlier about what you want to accomplish, it
> seems a chroot jail is what you want for your users.  Why reinvent the
> wheel?  Of course you can beat SELinux into doing what you're asking,
> but that's not really what it was designed to directly accomplish.

I suppose that this depends on what he needs.  If he wants a completely
isolated directory tree for each user and he wants this to be transparent
to applications, then using chroot makes sense, although I would still
suggest using SELinux to confine any damage if the chroot jail is broken
and to protect the integrity of the base system.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Hi again,

I am trying to get through the documentation to get a better idea as to how and 
go about these things, but just a small question, ok.

If I do this on the original every.te

sed "s/domain/~be_domain/g" every.te > newevery.te
mv newevery.te every.te

Then in my new file "be_user.te"

I have replaced
"user_t" with "be_user_t" 
"define('user_domain'," with "define('be_domain',"
"user_domain(user)" with "be_domain(be_user)"
"type user_t domain userdomain" with "type be_user_t domain be_userdomain"

then when I go to the policy directory and do "make" I get the error unknown 
type 'be_domain'

could there be a problem in that it is looking for ~be_domain although I 
thought that"~" was for "not"

I'll work on getting more of the reading done as well.
cheers'
Lonnie

Quoting Stephen Smalley <sds@tislabs.com>:

> 
> On Wed, 19 Dec 2001 lonnie@outstep.com wrote:
> 
> > Actually I found out that I had to use the original unchanged every.te
> as well
> > as changing the be_domain back to domain in the be_user.te file.
> 
> No, that isn't right.  If you use the original every.te file and you
> keep
> the "domain" attribute on your new domain, then the rules in every.te
> will
> be applied to your new domain, which is more permissive than you want. 
> As
> I said originally, you must either change every.te to exclude your new
> domain or you must not use the "domain" attribute on your new domain. 
> The
> first option seems preferable (changing every.te).
> 
> Please make sure that you've read the available documentation
> regarding
> the policy before proceeding any further.  Randomly making changes
> without
> any understanding of what you are doing is unlikely to produce the
> desired
> result.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 
> 
> 

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[lonnie]

Hi Gary,

One of the main problems that we have found while investigating the "chroot" 
options was that when the system is running in "init 5" (graphical xwindows) 
and the chrooted program is in place then the user cannot move out of their 
directory from a shell. This also work great for "init 3" (text mode).

The fundamental problem is when you start an application once your window 
manager such as kde has been started. If you start Netscape, or OpenOffice for 
example the the user is free to navigate all over the system and effectively 
breaks out of the 'chrooted' environment.

this is why we have been looking to do it from many other possible directions 
although there does not seem to be any easy method for this.

Cheers,
Lonnie

Quoting Gary Lowder <gary@lowder.com>:

> Lonnie,
> 
> I hate to completely change the direction you're headed but...
> Based on what you've said earlier about what you want to accomplish, it
> 
> seems a chroot jail is what you want for your users.  Why reinvent the
> 
> wheel?  Of course you can beat SELinux into doing what you're asking, 
> but that's not really what it was designed to directly accomplish.
> 
> Largo, Florida, implemented a linux system for it's municipality workers
> 
> to use.  A base link off of which you might find lots of useful 
> information is:  http://www.consultingtimes.com/Largo.html
> He didn't do exactly what you're talking about, but it's not far off.
> 
> Where I would actually start, is a site to help explain and set up a 
> chroot jail, one of I'm sure many sites is: 
> http://www.gsyc.inf.uc3m.es/~assman/jail/1.html
> 
> I'm sure there are others out there.
> 
> With a large enough hammer it is entirely possible to beat a square peg
> 
> into a round hole, but it's much easier to just find the round peg.
> 
> Hope this helps you accomplish your objectives.
> 
> Gary.
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux
> 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.
> 

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Stephen Smalley]

On Wed, 19 Dec 2001 lonnie@outstep.com wrote:

> If I do this on the original every.te
>
> sed "s/domain/~be_domain/g" every.te > newevery.te
> mv newevery.te every.te
>
> Then in my new file "be_user.te"
>
> I have replaced
> "user_t" with "be_user_t"
> "define('user_domain'," with "define('be_domain',"
> "user_domain(user)" with "be_domain(be_user)"
> "type user_t domain userdomain" with "type be_user_t domain be_userdomain"
>
> then when I go to the policy directory and do "make" I get the error unknown
> type 'be_domain'

In your every.te file, you are using the name of your macro
(be_domain) rather than the name of your domain (be_user_t).
Unfortunately, fixing that error won't actually help you, due
to a limitation in the current policy language/compiler.  I erred in
suggesting this approach; you should go back to not using the "domain"
type attribute with your new domain and leave every.te unmodified (but
remove the assertion from assert.te).  Sorry.

I doubt that many of the other subscribers to this list are interested in
this discussion any further, so you may want to take it off-list as a
courtesy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Russell Coker]

On Wed, 19 Dec 2001 19:34, Stephen Smalley wrote:
> > looking back on the list, I saw some people have discussed using Debian
> > Linux with the SELinux patch.  I was wondering if that ever came to
> > anything other than talk.  I am currently working on setting up a test
> > machine with Debian Testing (on x86) and SE Linux.  (ATM, I am still
> > sorting out ext3 + initrd... can't believe there isn't a cleaner
> > solution).
>
> Russell Coker has a Debian kernel-patch package for SELinux at
> http://www.coker.com.au/selinux.  I don't know whether the Debian folks
> have made any progress with the daemon and utility patches or the example
> policy configuration.

I am still (slowly) working on this.  I hope to have all the basics packaged 
by the end of the week...

> I'm not sure what you mean when you say
> "I am still sorting out ext3 + initrd."  The current release of SELinux
> works fine with ext3 - we were just waiting for ext3 to be merged into the
> mainstream kernel, and it is present in the 2.4.16 kernel.  As far as
> initrd is concerned, you can probably make it work if you really need it.
> I think you just need to create an initrd image that includes a copy of the
> compiled policy configuration so that it is available.

Having the policy on the initrd is painful.  I think that the best solution 
is to turn on the SE functionality after the root FS has been mounted (if 
they can crack your machine at initrd time you're pretty much stuffed 
anyway).  Stephen, I got the impression from a previous message that such 
delayed startup of SE functionality is possible with the 
CONFIG_SECURITY_SELINUX_DEVELOP option, but I haven't looked into that yet.

> > Looking at the way SELinux works, I assume I will have at least to alter
> > the policies because of the differences in paths?
>
> You will need to adapt the daemon and utility patches to the corresponding
> Debian packages, although only a few of these patches are critical (login,
> sshd, crond).  You will have to customize setfiles/file_contexts for your
> filesystem layout.  If you build with NSA SELinux Development Module
> option, then you can run your system in permissive mode for a while to
> collect audit messages, and can then work on customizing the policy
> configuration based on those audit messages, possibly using Justin Smith's
> perl script.

-- 
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/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

--
You have received this message because you are subscribed to the selinux 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: setting up new test user domain?

[Russell Coker]

On Wed, 19 Dec 2001 20:18, Flood Randy Capt AFCA/TCAA wrote:
> But, under certain circumstances, chrooted jails can be broken out of.
> Right?
>
> For example, see:
>
> http://www.bpfh.net/simes/computing/chroot-break.html
>
> Is this information dated?  Is chroot really more reliable now?  Isn't
> the whole concept of type enforcement to give an additional layer of
> security in such cases?

I think that information is still current.

However please note that only root can do chroot().  So if you have 
permissions to do chroot() then you can also mount the proc file system, use 
it to discover what the root device is, do an mknod of a matching device 
file, and then get raw access to the file system.

Or if you have devfs compiled in then you can mount it under the chroot and 
get access to the device nodes.

For good security programs in a chroot() environment should be blocked from 
mount() and chroot() system calls.

To get this use the GRSecurity patch for Linux 2.4.x 
http://www.grsecurity.net/ .  However please note that at this time it's 
incompatible with LSM...

I'm about to write a message to the author requesting that it work with LSM 
(but it'll be some significant coding for them and won't be done quickly).

-- 
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/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Stephen Smalley]

On Thu, 20 Dec 2001, Russell Coker wrote:

> Having the policy on the initrd is painful.  I think that the best solution
> is to turn on the SE functionality after the root FS has been mounted (if
> they can crack your machine at initrd time you're pretty much stuffed
> anyway).  Stephen, I got the impression from a previous message that such
> delayed startup of SE functionality is possible with the
> CONFIG_SECURITY_SELINUX_DEVELOP option, but I haven't looked into that yet.

SELinux initially tries to load the security policy configuration when the
LSM post_mountroot hook is called after the root filesystem has been
mounted.  However, I think that if an initrd is used, this occurs when the
initrd is mounted as the initial root filesystem, so if the policy isn't
on the initrd, you have a problem.  But I haven't actually tried using an
initrd with SELinux for a long time, and it hasn't been a priority for us.

With the current SELinux release, the kernel will panic if it can't load
the policy configuration when the root filesystem is mounted, regardless
of whether the Development option is enabled.  I've started making some
changes to the SELinux initialization code that will permit a delayed load
if this initial load fails when the Development option is enabled, but
this change isn't in the current release.  If the initial load fails
while booting a development kernel, it is probably sufficient to defer
loading until the system is toggled into enforcing mode.  At that point,
if SELinux still can't load the policy, it should probably panic rather
than allowing the system to proceed in an insecure state.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com







--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Noah silva]

> > Russell Coker has a Debian kernel-patch package for SELinux at
> > http://www.coker.com.au/selinux.  I don't know whether the Debian folks

I am just using the LSM kernel found on NSA's page, with ext3 enabled.

> > I'm not sure what you mean when you say
> > "I am still sorting out ext3 + initrd."  The current release of SELinux
> > works fine with ext3 - we were just waiting for ext3 to be merged into the
> > mainstream kernel, and it is present in the 2.4.16 kernel.  As far as
> > initrd is concerned, you can probably make it work if you really need it.
> > I think you just need to create an initrd image that includes a copy of the
> > compiled policy configuration so that it is available.

what I meant here was "still sorting out ext3" by itself, before working
on attempting to get it to work with SELinux.  (though I heard it should
be no real problem.).

What I meant was I don't quite understand why they did what they did with
initrd.  If it isn't possible to have it simply boot root as ext3, why not
boot it as ext2 and then remount it as ext3 later in the process?  Am I
missing something?

> Having the policy on the initrd is painful.  I think that the best solution 

oh no, I wasn't going to do that!

> is to turn on the SE functionality after the root FS has been mounted (if 
> they can crack your machine at initrd time you're pretty much stuffed 
> anyway).  Stephen, I got the impression from a previous message that such 
> delayed startup of SE functionality is possible with the 
> CONFIG_SECURITY_SELINUX_DEVELOP option, but I haven't looked into that yet.

I was going to ask exactly how you toggle the enforcement with the debug
options.  (I am sure it is in the FAQ somewhere, and I am just blind
though.).


 thanks,
     noah silva 


--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Stephen Smalley]

On Thu, 20 Dec 2001, Noah silva wrote:

> I was going to ask exactly how you toggle the enforcement with the debug
> options.  (I am sure it is in the FAQ somewhere, and I am just blind
> though.).

Just for future reference, this is discussed in step 19 of the README and
in the help text (from the make menuconfig) for the Development option.
When built with the Development option, the SELinux module starts in
permissive mode and can be toggled into enforcing mode using the
avc_toggle program.  But be sure that the policy configuration is
sufficient for your system to continue operating before toggling into
enforcing mode.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Noah silva]

> > options.  (I am sure it is in the FAQ somewhere, and I am just blind
> > though.).
> 
> Just for future reference, this is discussed in step 19 of the README and
> in the help text (from the make menuconfig) for the Development option.
> When built with the Development option, the SELinux module starts in
> permissive mode and can be toggled into enforcing mode using the
> avc_toggle program. 

I would think that having it in development mode then could be somewhat of
a security hazard in itself. (if an attacker were somehow able to run the
avc_toggle program).  I assume it is recommended to turn off the
development mode for production systems after developing the policies on a
test system.

> But be sure that the policy configuration is
> sufficient for your system to continue operating before toggling into
> enforcing mode.

lol I suppose that could be a problem.  I am, however keeping several
kernels on the test machien at this point for recovery from any mistakes I
make.

-- noah silva  


--
You have received this message because you are subscribed to the selinux 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: Debian SE Linux ?

[Stephen Smalley]

On Thu, 20 Dec 2001, Noah silva wrote:

> I would think that having it in development mode then could be somewhat of
> a security hazard in itself. (if an attacker were somehow able to run the
> avc_toggle program).  I assume it is recommended to turn off the
> development mode for production systems after developing the policies on a
> test system.

This is also discussed in step 19 of the README and in the help text for
the option.   RTM!

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.