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.From: Stephen Smalley <sds_at_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
> 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.From: lonnie_at_outstep.com
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.From: Stephen Smalley <sds_at_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.From: lonnie_at_outstep.com
Well, I actually have opted to go with Option #2 and have:
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.From: lonnie_at_outstep.com
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.From: Stephen Smalley <sds_at_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.From: Gary Lowder <gary_at_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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: lonnie_at_outstep.com
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.From: Noah silva <nsilva_at_atari-source.com>
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?
-- 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.From: Stephen Smalley <sds_at_tislabs.com>
> 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.From: Russell Coker <russell_at_coker.com.au>
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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Noah silva <nsilva_at_atari-source.com>
> > 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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Noah silva <nsilva_at_atari-source.com>
> > 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.
-- 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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: lonnie_at_outstep.com
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.From: Stephen Smalley <sds_at_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.From: lonnie_at_outstep.com
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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Flood Randy Capt AFCA/TCAA <randy.flood_at_scott.af.mil>
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.
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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT