restricted guest domain accounts

restricted guest domain accounts

[Lonnie Cumberland]

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.

Re: restricted guest domain accounts

[Tom]

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.

Re: restricted guest domain accounts

[Lonnie Cumberland]

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.

Re: restricted guest domain accounts

[Shaun Savage]

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.

Re: restricted guest domain accounts

[Lonnie Cumberland]

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.

Re: restricted guest domain accounts

[Stephen Smalley]

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.

Re: restricted guest domain accounts

[Stephen Smalley]

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.

Re: restricted guest domain accounts

[Stephen Smalley]

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.

Re: restricted guest domain accounts

[Tom]

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.