Re: Domain transition

Re: Domain transition

[Justin Smith]

I think domain transition is one of the key security features of
SELinux:

The one domain with high privileges similar to the old root privileges
is the initrc_t domain. But transitions cause this domain to "cease to
exist" by the time Linux has completely booted.
--



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Russell Coker]

On Tue, 17 Dec 2002 13:52, Justin Smith wrote:
> The one domain with high privileges similar to the old root privileges
> is the initrc_t domain.

It seems that initrc_t only really lacks the ability to write to arbitary 
files.  It can ifconfig interfaces (needed for network start scripts), start 
and stop daemons (it's primary purpose), and see everything in "ps ax".

> But transitions cause this domain to "cease to
> exist" by the time Linux has completely booted.

No, there's "run_init" to run scripts in that domain to start daemons.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Stephen D. Smalley]

> 1)    What is "domain transition"?  I've configured my system such that it
> doesn't happen, but I'm wondering if it's the best way to go.

Read the Configuring the SELinux Policy report, available in the
distribution (selinux/doc/policy) or from the NSA SELinux web site.
You might also want to read a background paper on Type Enforcement (TE).

A domain is a security attribute associated with a process.  Processes with the 
same domain have the same set of permissions to the same set of objects. A 
domain transition occurs when a process changes its domain, conventionally by 
executing a program with a particular entrypoint type.  Domain transitions 
provide a controlled mechanism for changes in permissions, whether to gain 
permissions, shed permissions, or switch to a completely orthogonal set of 
permissions.  I doubt that you really configured away domain transitions. If you 
did, you might as well not use SELinux.

> 2)    Is there a text file on my system with the list of user roles or is
> that information stored some other way?

In the source distribution's selinux tree, the policy/users file specifies the 
set of roles authorized for each user.  Obtaining the full set of defined roles
is not entirely straightforward because role declarations are now distributed
among the domain .te files.  Roles for user processes are typically defined
in policy/domains/user.te or policy/domains/admin.te.  You may want to look at 
the Tresys policy tools as a way of more easily viewing the policy or managing 
users.

In an installed form, the policy sources are typically placed into 
/etc/security/selinux/src/policy.

> 3)    Can I configure the operating system NOT to ask for a user role on
> login?  I would much prefer to have user role determined BY the login.

The user will be limited to the roles authorized for that user in
policy/users.  If you authorize the user for multiple roles, then he
can choose one of those roles at login time or subsequently via newrole.
What's the point of limiting the user to a single role at login time if he can 
change it subsequently via newrole?  Of course, you could limit login
to transition to a single user domain if you want to force all users to
initially login with a certain role/domain.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Russell Coker]

On Mon, 16 Dec 2002 22:25, Stephen D. Smalley wrote:
> What's the point of limiting the user to a single role at login time if he
> can change it subsequently via newrole?  Of course, you could limit login
> to transition to a single user domain if you want to force all users to
> initially login with a certain role/domain.

We currently have the default policy for sshd not allowing it to transition to 
sysadm_t to limit the damage from sshd being cracked.

I guess there's potential for a very paranoid (*) person to want to do the 
same with login.

(*)  /bin/login has had a good history in terms of security for almost 10 
years now, unlike sshd.  Also /bin/login can't be accessed anywhere nearly as 
easily as sshd.  Of course I'm sure there are some very paranoid people 
here...  ;)

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Brian May]

On Mon, Dec 16, 2002 at 11:07:52PM +0100, Russell Coker wrote:
> (*)  /bin/login has had a good history in terms of security for almost 10 
> years now, unlike sshd.  Also /bin/login can't be accessed anywhere nearly as 

Assuming you are not using telnet...

(and yes, you can use Kerberos Telnet or SSL-Telnet too, so telnet
doesn't always have to mean insecure; with these protocols you need to
be authenticated though before login is run).
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Russell Coker]

On Tue, 17 Dec 2002 00:11, Brian May wrote:
> On Mon, Dec 16, 2002 at 11:07:52PM +0100, Russell Coker wrote:
> > (*)  /bin/login has had a good history in terms of security for almost 10
> > years now, unlike sshd.  Also /bin/login can't be accessed anywhere
> > nearly as
>
> Assuming you are not using telnet...

Telnet causes login to be run as remote_login_t which is distinguished from 
the main local_login_t domain for this reason.

Actually we should probably have ifdef(`rlogin.te',` around the definition of 
remote_login_t in login.te, and have a similar ifdef(`login.te', ` in 
rlogin.te.

> (and yes, you can use Kerberos Telnet or SSL-Telnet too, so telnet
> doesn't always have to mean insecure; with these protocols you need to
> be authenticated though before login is run).

SSL-Telnet would be OK apart from it's history of security holes.

Kerberos still isn't safe, proxying the telnet protocol and hijacking it is 
not overly difficult...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Brian May]

On Tue, Dec 17, 2002 at 10:19:27AM +0100, Russell Coker wrote:
> > (and yes, you can use Kerberos Telnet or SSL-Telnet too, so telnet
> > doesn't always have to mean insecure; with these protocols you need to
> > be authenticated though before login is run).
> 
> SSL-Telnet would be OK apart from it's history of security holes.

Yes. At one stage a group of Debian developers looked at 2 to 4
different implementations of SSL-Telnet, trying to work out which
was the best one.

The conclusion, IIRC, was that all of them were pretty awful,
just some had more features then others.

> Kerberos still isn't safe, proxying the telnet protocol and hijacking it is 
> not overly difficult...

Do you have a reference?
-- 
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Russell Coker]

On Tue, 17 Dec 2002 12:42, Brian May wrote:
> > Kerberos still isn't safe, proxying the telnet protocol and hijacking it
> > is not overly difficult...
>
> Do you have a reference?

Is one really needed?

Redirecting a port 23 connection to one on the local machine and then 
establishing a new connection to the server is quite easy if you control a 
router.  Going from that to taking over an idle session is quite easy.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Brian May]

On Tue, Dec 17, 2002 at 02:31:52PM +0100, Russell Coker wrote:
> On Tue, 17 Dec 2002 12:42, Brian May wrote:
> > > Kerberos still isn't safe, proxying the telnet protocol and hijacking it
> > > is not overly difficult...
> >
> > Do you have a reference?
> 
> Is one really needed?
> 
> Redirecting a port 23 connection to one on the local machine and then 
> establishing a new connection to the server is quite easy if you control a 
> router.  Going from that to taking over an idle session is quite easy.

Not if you have encryption enabled...
-- 
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Domain transition

[Richard Mayo]

I have a few questions, and I hope you good folks can help me out:


1)    What is "domain transition"?  I've configured my system such that it
doesn't happen, but I'm wondering if it's the best way to go.
2)    Is there a text file on my system with the list of user roles or is
that information stored some other way?
3)    Can I configure the operating system NOT to ask for a user role on
login?  I would much prefer to have user role determined BY the login.

I'm sure I'll have others, but I can't think of anything at this time.



R.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Domain transition

[Tom]

On Mon, Dec 16, 2002 at 03:09:59PM -0500, Richard Mayo wrote:
> 1)    What is "domain transition"?  I've configured my system such that it
> doesn't happen, but I'm wondering if it's the best way to go.

It's not. Domain transitions are necessary. It's something like the
SELinux equivalent of setuid. For example, when init starts apache, you
definitely do want the initrc domain to change into the apache domain.


> 2)    Is there a text file on my system with the list of user roles or is
> that information stored some other way?

look into /etc/security. it has changed around a little recently, but
there should be something like default_* in there with the information
you are looking for.


> 3)    Can I configure the operating system NOT to ask for a user role on
> login?  I would much prefer to have user role determined BY the login.

I'm sure it's possibly to skip the check, e.g. if the user is only
allowed to be in a single domain anyway. But I believe you would need
to patch the login code for this.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.