Hello All,
I hope that you are all doing well today.
Some time ago, I was asking about locking users to their home directory but have recently been thinking that may not be completely required for our project.
As such, I have been looking at MANY method and various Operating Systems such as OpenBSD, and the like for possible solutions to this original delima.
If I now go along the lines that I will not isolate the users to their home directories but instead use the most secure OS for the job then I once again arrive back at SELinux which I am starting to like more and more.
That being said, I have now gotten SELinux up and running on a freshly installed Redhat 7.2 server.
What I am not looking to do is to humbly ask for some help from the list to create a guest domain so that I can add new users to and they will have very restricted abilities on the server. A simple example would be great if someone might have one to share with me.
I have also printed out the documentation on the website and am now reading over it to try and get a feel for how I can do things.
I will next be installing OpenOffice/StarOffice on my SELinux server but would like not to allow the guest domain users to run many of the existing applications that are in the "/bin /sbin /usr/bin ...." directories.
Perhaps only allow them to run just a few that I will decide upon.
It appears that SELinux can easily be set up for such thing and I hope that someone will please help to guide me through these initial difficult learning times.
Best Regards,
Lonnie
-- Lonnie Cumberland OutStep Technologies Incorporated (313) 832-7366 URL: http://www.outstep.com EMAIL: Lonnie@OutStep.com : Lonnie_Cumberland@yahoo.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: Tom <tom_at_lemuria.org>
On Mon, Jan 21, 2002 at 12:06:31AM -0500, Lonnie Cumberland wrote:
> If I now go along the lines that I will not isolate the users to
> their home directories but instead use the most secure OS for the job
> then I once again arrive back at SELinux which I am starting to like
> more and more.
I have a very similiar problem. I need a remote-access server with multiple "public" access options (internet, analog and ISDN dialups) into a highly sensitive backend network. obviously, I *expect* it to be a target not only for the usual script kiddie rounds, but also for specific attacks from people who know at least the rough setup, maybe even insiders. the data stored on the backend is such that it may be of private interest to even the people who work with it (but obviously can't copy it overtly during worktime).
so for now - because as usual nobody really realizes that remote access
into your own backend means a little more than a convenience, and
there's of course a tight deadline - I'm using a locked-down, minimalistic
Debian system.
however, I would just love to lock it down much more. that's where
SELinux comes into play, because I believe here I can really put a
policy into play that says "after successful login, you are allowed to
execute exactly THESE three programs."
as a matter of fact, I wouldn't mind blocking a selection of system
calls that I know won't be needed. :)
> What I am not looking to do is to humbly ask for some help from the
> list to create a guest domain so that I can add new users to and they
> will have very restricted abilities on the server. A simple example
> would be great if someone might have one to share with me.
yes, please. I need a similiar example. I still have trouble understanding the flask concept details. I do believe I have the basics down (after 3rd reading), but I don't feel confident writing a policy, yet.
-- http://web.lemuria.org/pubkey.html pub 1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org> Key fingerprint = 276B B7BB E4D8 FCCE DB8F F965 310B 811A D88D 35A6 -- 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 Cumberland <lonnie_at_outstep.com>
I recently had an email from someone asking if I was running X on my
Redhat 7.2 with SELinux and the answer is yes.
I am responding in this way because I have unfortunately lost that particular email.
the way to get that to work is to edit the policy in the program/xserver.te and uncomment the 3 lines needed to enable the ease the xserver restrictions.
Cheers,
Lonnie
-- Lonnie Cumberland OutStep Technologies Incorporated (313) 832-7366 URL: http://www.outstep.com EMAIL: Lonnie@OutStep.com : Lonnie_Cumberland@yahoo.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 Mon, 21 Jan 2002, Lonnie Cumberland wrote:
> the way to get that to work is to edit the policy in the
> program/xserver.te and uncomment the 3 lines needed to enable the
> ease the xserver restrictions.
This is explained in the README.
-- 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: Shaun Savage <savages_at_pcez.com>
I hear the people wanting a guest user. I will try to make a user that
can login but that is all. Then let you change the policy. You may have
to change the context of some programs to system_u:object_r:guest_bin_t
this allows the guest account to access the guest_bin_t object but not bin_t objects.
Shaun
Tom wrote:
>On Mon, Jan 21, 2002 at 12:06:31AM -0500, Lonnie Cumberland wrote:
>
>>If I now go along the lines that I will not isolate the users to
>>their home directories but instead use the most secure OS for the job
>>then I once again arrive back at SELinux which I am starting to like
>>more and more.
>>
>
>I have a very similiar problem. I need a remote-access server with
>multiple "public" access options (internet, analog and ISDN dialups)
>into a highly sensitive backend network. obviously, I *expect* it to be
>a target not only for the usual script kiddie rounds, but also for
>specific attacks from people who know at least the rough setup, maybe
>even insiders. the data stored on the backend is such that it may be of
>private interest to even the people who work with it (but obviously
>can't copy it overtly during worktime).
>
>so for now - because as usual nobody really realizes that remote access
>into your own backend means a little more than a convenience, and
>there's of course a tight deadline - I'm using a locked-down, minimalistic
>Debian system.
>however, I would just love to lock it down much more. that's where
>SELinux comes into play, because I believe here I can really put a
>policy into play that says "after successful login, you are allowed to
>execute exactly THESE three programs."
>as a matter of fact, I wouldn't mind blocking a selection of system
>calls that I know won't be needed. :)
>
>
>>What I am not looking to do is to humbly ask for some help from the
>>list to create a guest domain so that I can add new users to and they
>>will have very restricted abilities on the server. A simple example
>>would be great if someone might have one to share with me.
>>
>
>yes, please. I need a similiar example. I still have trouble
>understanding the flask concept details. I do believe I have the basics
>down (after 3rd reading), but I don't feel confident writing a policy,
>yet.
>
>
-- 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 Cumberland <lonnie_at_outstep.com>
That would be wonderful Shaun.
I also think that it would go along way in helping people(especially me) to understand how to work with SELinux.
Thanks for the work and I REALLY look forward to seeing your results.
Lonnie
> I hear the people wanting a guest user. I will try to make a
> user that can login but that is all. Then let you change the
> policy. You may have to change the context of some programs to
> system_u:object_r:guest_bin_t
> this allows the guest account to access the guest_bin_t object
> but
> not bin_t objects.
>
> Shaun
>
>
> Tom wrote:
>
>>On Mon, Jan 21, 2002 at 12:06:31AM -0500, Lonnie Cumberland
>>wrote:
>>
>>>If I now go along the lines that I will not isolate the users to
>>>their home directories but instead use the most secure OS for
>>>the job then I once again arrive back at SELinux which I am
>>>starting to like more and more.
>>>
>>
>>I have a very similiar problem. I need a remote-access server
>>with multiple "public" access options (internet, analog and ISDN
>>dialups) into a highly sensitive backend network. obviously, I
>>*expect* it to be a target not only for the usual script kiddie
>>rounds, but also for specific attacks from people who know at
>>least the rough setup, maybe even insiders. the data stored on
>>the backend is such that it may be of private interest to even
>>the people who work with it (but obviously can't copy it overtly
>>during worktime).
>>
>>so for now - because as usual nobody really realizes that remote
>>access into your own backend means a little more than a
>>convenience, and there's of course a tight deadline - I'm using a
>>locked-down, minimalistic Debian system.
>>however, I would just love to lock it down much more. that's
>>where SELinux comes into play, because I believe here I can
>>really put a policy into play that says "after successful login,
>>you are allowed to execute exactly THESE three programs."
>>as a matter of fact, I wouldn't mind blocking a selection of
>>system calls that I know won't be needed. :)
>>
>>
>>>What I am not looking to do is to humbly ask for some help from
>>>the list to create a guest domain so that I can add new users to
>>>and they will have very restricted abilities on the server. A
>>>simple example would be great if someone might have one to share
>>>with me.
>>>
>>
>>yes, please. I need a similiar example. I still have trouble
>>understanding the flask concept details. I do believe I have the
>>basics down (after 3rd reading), but I don't feel confident
>>writing a policy, yet.
-- Lonnie Cumberland OutStep Technologies Incorporated (313) 832-7366 URL: http://www.outstep.com EMAIL: Lonnie@OutStep.com : Lonnie_Cumberland@yahoo.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 Mon, 21 Jan 2002, Tom wrote:
> there's of course a tight deadline - I'm using a locked-down, minimalistic
> Debian system.
> however, I would just love to lock it down much more. that's where
> SELinux comes into play, because I believe here I can really put a
> policy into play that says "after successful login, you are allowed to
> execute exactly THESE three programs."
> as a matter of fact, I wouldn't mind blocking a selection of system
> calls that I know won't be needed. :)
It seems like using SELinux on this system would be beneficial even without a special guest user domain. The example policy provides a user_t domain for ordinary users that is already limited, e.g. even if such a user obtains superuser privileges, he cannot modify the system software, configuration files, or logs. The issue is not what programs can be run by the user but what permissions are granted to domains that can be entered by the user. You could strip the user_t domain down further if desired, but you need to consider whether you are really improving security by doing so. With regard to system calls, SELinux doesn't interpose on system calls - it provides low-level controls over the actual kernel operations on kernel objects.
-- 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: Tom <tom_at_lemuria.org>
On Tue, Jan 22, 2002 at 02:28:51PM -0500, Stephen Smalley wrote:
> It seems like using SELinux on this system would be beneficial even
> without a special guest user domain. The example policy provides a user_t
> domain for ordinary users that is already limited, e.g. even if such a
> user obtains superuser privileges, he cannot modify the system software,
> configuration files, or logs. The issue is not what programs can be run
> by the user but what permissions are granted to domains that can be
> entered by the user. You could strip the user_t domain down further if
> desired, but you need to consider whether you are really improving
> security by doing so. With regard to system calls, SELinux doesn't
> interpose on system calls - it provides low-level controls over the actual
> kernel operations on kernel objects.
thanks - as I said, I still haven't understood all of it.
what I want is, essentially, a user that can do exactly two things: log in, and connect out again, with a small set of tools (ssh and telnet, currently). that's it. he shouldn't be able to run anything else on the machine. no looking at the process table, no ping'ing, no starting daemons, nothing.
I'm not so much troubled about the users obtaining root, as the users using the machine for a purpose other than the one specified.
-- http://web.lemuria.org/pubkey.html pub 1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org> Key fingerprint = 276B B7BB E4D8 FCCE DB8F F965 310B 811A D88D 35A6 -- 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 Mon, 21 Jan 2002, Lonnie Cumberland wrote:
> I will next be installing OpenOffice/StarOffice on my SELinux server
> but would like not to allow the guest domain users to run many of the
> existing applications that are in the "/bin /sbin /usr/bin ...."
> directories.
>
> Perhaps only allow them to run just a few that I will decide upon.
What do you hope to achieve by this restriction? What do you gain in security by preventing a user from running a program in /bin if he can run OpenOffice/StarOffice? Do you really care what programs can be run by the user, or just what processes and files he can access, regardless of the program that he happens to use?
-- 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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT