Re: Domain transition -- enabling user_r in eklogin

Re: Domain transition -- enabling user_r in eklogin

[forrest whitcher]

On Tue, 17 Dec 2002 14:31:52 +0100 
Russell Coker <russell@coker.com.au> did inscribe thusly:

> 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.
> 

Which is a good reason to use eklogin / 3des encription over kerberized
rlogin. 


For which I've been having problems getting an appropriate transition working.
(the following may have some typos I don't have either box running just now
to refer to)

The remote_login domain was clearly designed with telnet in mind, there is
no transtion to user_u:user_r.

Looking this over I moved login.krb5 into the same SID as /bin/login, using
login.te as an example, however once the user's successfully authenticated
the domain remains system_u:system_r and 'newrole(1)' is not available.

I'm going somewhat from memory so there may be some missed details, however
I've tried re-configuring several times without much luck.

Also this test is being done on a slackware setup, because I was able to
get telnetd working in a redhat system more easily there may be some system 
layout issues causing problems, not sure yet.

forrest

--
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 -- enabling user_r in eklogin

[Stephen D. Smalley]

> For which I've been having problems getting an appropriate transition working.
> (the following may have some typos I don't have either box running just now
> to refer to)
> 
> The remote_login domain was clearly designed with telnet in mind, there is
> no transtion to user_u:user_r.
> 
> Looking this over I moved login.krb5 into the same SID as /bin/login, using
> login.te as an example, however once the user's successfully authenticated
> the domain remains system_u:system_r and 'newrole(1)' is not available.
> 
> I'm going somewhat from memory so there may be some missed details, however
> I've tried re-configuring several times without much luck.
> 
> Also this test is being done on a slackware setup, because I was able to
> get telnetd working in a redhat system more easily there may be some system 
> layout issues causing problems, not sure yet.

The example policy includes rules to transition from inetd_t or tcpd_t to 
rlogind_t upon executing a file labeled with the rlogind_exec_t type (assigned 
to in.rlogind and in.telnetd in the file contexts configuration), and to 
transition from rlogind_t to remote_login_t upon executing a file labeled with 
the login_exec_t type (assigned to login in the file contexts configuration).  
The remote_login_t domain can then transition to user_t, at which point
the user can run newrole if the user has an entry in the policy/users
file and is authorized for any other roles.  If the user lacks an entry in the 
policy/users file and you retain the user_u entry in policy/users, then the user 
will be mapped to the generic user_u identity for the SELinux security context 
and will be limited to operating in user_r.

--
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 -- enabling user_r in eklogin

[forrest whitcher]

On Tue, 17 Dec 2002 11:14:38 -0500 (EST) (unchecked - local sync NTPstrat4)
"Stephen D. Smalley" <sds@epoch.ncsc.mil> did inscribe thusly:

fw:
> > 
> > Also this test is being done on a slackware setup, because I was able to
> > get telnetd working in a redhat system more easily there may be some system 
> > layout issues causing problems, not sure yet.
> 
"Stephen D. Smalley" <sds@epoch.ncsc.mil> 

> The example policy includes rules to transition from inetd_t or tcpd_t to 
> rlogind_t upon executing a file labeled with the rlogind_exec_t type (assigned 
> to in.rlogind and in.telnetd in the file contexts configuration), and to 
> transition from rlogind_t to remote_login_t upon executing a file labeled with 
> the login_exec_t type (assigned to login in the file contexts configuration).  
> The remote_login_t domain can then transition to user_t, at which point
> the user can run newrole if the user has an entry in the policy/users
> file and is authorized for any other roles.  If the user lacks an entry in the 
> policy/users file and you retain the user_u entry in policy/users, then the user 
> will be mapped to the generic user_u identity for the SELinux security context 
> and will be limited to operating in user_r.
> 

Stephen, Ok, I see you're right, I'd thought that this: (login.te)
--
# Only permit unprivileged user domains to be entered via rlogin,
# since very weak authentication is used.
domain_trans(remote_login_t, shell_exec_t, unpriv_userdomain)
--

was the source of the behavior, that wasn't it, local console login was also
broken and like an idiot I hadn't connected this, on console login also, the
context is system_u:system_r and I get the following messages:

avc:  denied  { ioctl } for  pid=142 exe=/bin/bash path=/dev/tty1 dev=08:02 ino=22757 scontext=system_u:system_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file
avc:  denied  { ioctl } for  pid=142 exe=/bin/bash path=/dev/tty1 dev=08:02 ino=22757 scontext=system_u:system_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file

Those failures kill the shell in enforcing mode of course.

so some transition in the local_login domain is missing, I'll try to dig out the
root of that problem. ssh login is working fine on the slackware installation.

forrest


> --
> 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 -- enabling user_r in eklogin

[Stephen D. Smalley]

> avc:  denied  { ioctl } for  pid=142 exe=/bin/bash path=/dev/tty1 dev=08:02 
ino=22757 scontext=system_u:system_r:user_t 
tcontext=system_u:object_r:tty_device_t tclass=chr_file
> avc:  denied  { ioctl } for  pid=142 exe=/bin/bash path=/dev/tty1 dev=08:02 
ino=22757 scontext=system_u:system_r:user_t 
tcontext=system_u:object_r:tty_device_t tclass=chr_file

This looks like you aren't using the SELinux-patched login program.
The login process needs to set the security context for the user session
and to relabel the tty based on that security context.  If you use an
unmodified login, you'll get the behavior above.

--
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 -- enabling user_r in eklogin

[forrest whitcher]

On Tue, 17 Dec 2002 12:25:33 -0500 (EST) 
"Stephen D. Smalley" <sds@epoch.ncsc.mil> did inscribe thusly:

>
> This looks like you aren't using the SELinux-patched login program.
> The login process needs to set the security context for the user session
> and to relabel the tty based on that security context.  If you use an
> unmodified login, you'll get the behavior above.
> 

Ahh thanks! that was indeed it, darned if I can figure out why /bin/login
wasn't correctly replaced in the 'make install', but anyhow once login
and login.krb5 are replaced with the patched version, yes all works 
nicely.

I'll look into adding kerberos auth to newrole(1) to save retypings of
password next.

forrest

--
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 -- enabling user_r in eklogin

[Brian May]

On Tue, Dec 17, 2002 at 07:28:56PM -0500, forrest whitcher wrote:
> I'll look into adding kerberos auth to newrole(1) to save retypings of
> password next.

Interesting idea, it would be good not to have to type in your password
each time.

However, I have to wonder if this is such a good idea...

At the very least you would need to have a strict policy that only
allows very trusted programs to access the ticket or to run a program
(eg. newrole) that has access to this ticket.

This might be a good thing anyway, you probably don't want a copy of
mozilla being able to automatically run commands on remote computer with
your Kerberos ticket for instance.

If there is any weakness in this strict policy, and for instance program
X finds it can run newrole indirectly via, say bash, and automatically
get sysadm_r priviliges, you loose any benifit SE-Linux could provide.

Some sort of tool for analysing policy might be good here, for instance
so you can ask questions like "Can Mozilla access the Kerberos ticket
either directly or indirectly by loading another program first?".

I am not yet sure how good SE-Linux will be at solving this type of
problem, without duplicating a lot of domains, for instance
a set of domains for programs with Kerberos ticket access, and
a duplicate set for programs without Kerberos ticket access).
--
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 -- enabling user_r in eklogin

[Russell Coker]

On Wed, 18 Dec 2002 02:28, Brian May wrote:
> On Tue, Dec 17, 2002 at 07:28:56PM -0500, forrest whitcher wrote:
> > I'll look into adding kerberos auth to newrole(1) to save retypings of
> > password next.
>
> Interesting idea, it would be good not to have to type in your password
> each time.

Which is something you could easily achieve through PAM configuration if that 
is what you desire, without any kerberos issues etc.

> However, I have to wonder if this is such a good idea...
>
> At the very least you would need to have a strict policy that only
> allows very trusted programs to access the ticket or to run a program
> (eg. newrole) that has access to this ticket.

As newrole can't be ptraced etc it should be safe to be trusted with the 
ticket.  But it doesn't make sense IMHO to be doing such things.

> If there is any weakness in this strict policy, and for instance program
> X finds it can run newrole indirectly via, say bash, and automatically
> get sysadm_r priviliges, you loose any benifit SE-Linux could provide.

No.

Programs in domains such as user_netscape_t and user_irc_t will not be allowed 
to run newrole at all.

Newrole will still only allow transitions to roles that are permitted (so if a 
user is not permitted sysadm_r then they still can't get it).

Daemons will still run in separate domains to protect against each other and 
against regular system users.

Allowing role transitions without password loses you some of the benefits of 
SE Linux, but not even most of them.

Also I think that in most situations where a user could be tricked into 
running newrole then it's game-over anyway.

> Some sort of tool for analysing policy might be good here, for instance
> so you can ask questions like "Can Mozilla access the Kerberos ticket
> either directly or indirectly by loading another program first?".

I think that Trent is working on such tools.  But this is a simple case that 
can be addressed by grep:
grep allow.*netscape.*process.transition policy.conf
Shows that user_netscape_t can only transition to user_lpr_t (and similar 
transitions for sysadm_netscape_t and httpd_admin_netscape_t).

grep allow.*_lpr_t.*process.transition policy.conf
Shows that user_lpr_t etc can't transition to any domain.

So netscape is safe in this regard.

> I am not yet sure how good SE-Linux will be at solving this type of
> problem, without duplicating a lot of domains, for instance
> a set of domains for programs with Kerberos ticket access, and
> a duplicate set for programs without Kerberos ticket access).

What exactly is "ticket access" and how does it conceptually differ from read 
access to /etc/shadow?  Couldn't we just treat ticket access in the same way 
as access to /etc/shadow?

-- 
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 -- enabling user_r in eklogin

[Brian May]

On Wed, Dec 18, 2002 at 08:45:22AM +0100, Russell Coker wrote:
> Which is something you could easily achieve through PAM configuration if that 
> is what you desire, without any kerberos issues etc.

How would you do it with PAM?

What security issues would this raise?

> Also I think that in most situations where a user could be tricked into 
> running newrole then it's game-over anyway.

OK. I was thinking more of scripts, etc.

> > I am not yet sure how good SE-Linux will be at solving this type of
> > problem, without duplicating a lot of domains, for instance
> > a set of domains for programs with Kerberos ticket access, and
> > a duplicate set for programs without Kerberos ticket access).
> 
> What exactly is "ticket access" and how does it conceptually differ from read 
> access to /etc/shadow?  Couldn't we just treat ticket access in the same way 
> as access to /etc/shadow?

There are several differences:

- the ticket is created by login/PAM or kinit, not sysadm_r.

- the ticket has a limited life time, so if somebody accesses it,
  its not quite as bad as somebody accessing one weak entry of the
  shadow file.

- more importantly, there are no immediate security risks by proving a
  trusted program access to the shadow file. It is not the
  authentication key, it is the lock.

However, a kerberos ticket is the key. So if you provide, say rsh access
to the ticket, any process that has ability to run rsh, directly via
exec, or indirectly, say via bash, can run commands like (note I don't
have a man page handy, so I can't check the parameters for certain) "rsh
remotehost rm -rf ."

Even worse is if this ticket allows root access...

So you might need some instances of bash that can run rsh, and
other instances that are used for running untrusted scripts that
cannot run rsh.

I talk about Kerberos tickets here, the same thing would also apply to
ssh-agent connections, with the exception that once the connection is
closed, it is no longer a security threat.
--
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 -- enabling user_r in eklogin

[Russell Coker]

On Wed, 18 Dec 2002 23:27, Brian May wrote:
> On Wed, Dec 18, 2002 at 08:45:22AM +0100, Russell Coker wrote:
> > Which is something you could easily achieve through PAM configuration if
> > that is what you desire, without any kerberos issues etc.
>
> How would you do it with PAM?

Put the following in /etc/pam.d/newrole:
auth    required        pam_permit.so

NB I'm not advocating doing this, just letting you know it's possible.

> What security issues would this raise?

It largely removes the point of having newrole.  In that case you should 
probably just permit each user exactly one role and give the default domain 
for that role the permissions required to do everything that they need to do.

One significant disadvantage is that a hacked sshd could run "newrole -r 
sysadm_r" and get that access (and this can be extended to other programs 
with a similar situation).

Of course if you allow someone the ability to transition to a role with less 
capabilities than their default role, and then denied them the ability to run 
the newrole program while in that role it might have some potential.

> > Also I think that in most situations where a user could be tricked into
> > running newrole then it's game-over anyway.
>
> OK. I was thinking more of scripts, etc.

It's the same thing.  If I can trick you into running some arbitary commands 
with your main role then I can get your ssh identity key and your gpg secret 
key.  These crypto keys are often worth more than the hardware that they are 
stored on...

-- 
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 -- enabling user_r in eklogin

[Jesse Pollard]

On Thursday 19 December 2002 03:51 am, Russell Coker wrote:
> On Wed, 18 Dec 2002 23:27, Brian May wrote:
> > On Wed, Dec 18, 2002 at 08:45:22AM +0100, Russell Coker wrote:
[-snip]
>
> One significant disadvantage is that a hacked sshd could run "newrole -r
> sysadm_r" and get that access (and this can be extended to other programs
> with a similar situation).
>
> Of course if you allow someone the ability to transition to a role with
> less capabilities than their default role, and then denied them the ability
> to run the newrole program while in that role it might have some potential.
>
> > > Also I think that in most situations where a user could be tricked into
> > > running newrole then it's game-over anyway.
> >
> > OK. I was thinking more of scripts, etc.
>
> It's the same thing.  If I can trick you into running some arbitary
> commands with your main role then I can get your ssh identity key and your
> gpg secret key.  These crypto keys are often worth more than the hardware
> that they are stored on...

Only if access is permitted to be over an unsecured channel.

The differentation between a local user and a remote user has to be provided.

Access to the secret key(s) probably should not be permitted from an
unsecured location/connection. This does require network labels to work.

Currently, as long as the Kerberos tickets have IP addresses embeded, the
TGT cannot be used on any system other than the host that generated them.
This restriction is frequently broken due to things like firwalls/NAT which do
not permit host IP identity to cross their boundary. I'm used to thinking of
these things with MLS, using multiple levels.. If the user connects over a
network, then the ticket cache should be labeled at the level of the
connection. Any lower level connection would not have access. If the user
then starts netscape, then netscape should be labeled at a lower access (or be
isolated via compartment) from the ticket cache. Any process that netscape
starts would also be created at that "lower" level. This includes things like
pgp keys. Only a trusted application should have access to them.

It does mean that the plugin for checking PGP signatures (at a minimum the
one for generating signatures) would have to be sufficiently separate from
the netscape process to be labeled separately. It could not use loadable
modules, for  instance. It also means any scripts started should not have
access either.

This is not a 100% solution - If netscape is used to download an application,
then the user proceeds to configure/compile/run then all bets are off since
the users actions are overriding the labels. It should/could prevent a trojan
from passing the files out though - it would not be authorized access to the
secret key(s) or the Kerberos ticket cache. Only trusted utilities would have
that capability.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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 -- enabling user_r in eklogin

[Russell Coker]

On Thu, 19 Dec 2002 15:02, Jesse Pollard wrote:
> > It's the same thing.  If I can trick you into running some arbitary
> > commands with your main role then I can get your ssh identity key and
> > your gpg secret key.  These crypto keys are often worth more than the
> > hardware that they are stored on...
>
> Only if access is permitted to be over an unsecured channel.
>
> The differentation between a local user and a remote user has to be
> provided.

The "if I can trick you" part means that the distinction between local and 
remote logins is probably not relevant.  Consider that you meet someone in 
Starbucks and say "there's this really cool program at www.foo.com" which 
they then download and run...

Of course we could deny execute access to user_home_t but variations on the 
same theme can always be used while there are users who can be tricked and 
net access for easy back-channels.

> Access to the secret key(s) probably should not be permitted from an
> unsecured location/connection. This does require network labels to work.

I guess you could have different roles, and have sshd only allow transitioning 
to a low security role which is prohibited from running ssh or gpg.  I wonder 
whether a domain that only has full access to user_home_dir_t and user_home_t 
can misdirect the actions of ssh or gpg...

I don't think that network labels allow us to do anything productive in this 
regard as network operations are so abstracted.  When a KDE ioslave can talk 
to a http proxy to get access to the outside network then making real use of 
network labels without seriously reducing functionality is almost impossible.

For my aims a significant reduction in functionality is unacceptable.

> It does mean that the plugin for checking PGP signatures (at a minimum the
> one for generating signatures) would have to be sufficiently separate from
> the netscape process to be labeled separately. It could not use loadable
> modules, for  instance. It also means any scripts started should not have
> access either.

The problem is that if you can run GPG currently you can encrypt the secret 
key to yourself with a password (IE not encrypting to a public key) and then 
decrypt the result to get the key.  A future version of GPG will address 
this.  I don't know how PGP performs in this regard.

> This is not a 100% solution - If netscape is used to download an
> application, then the user proceeds to configure/compile/run then all bets
> are off since the users actions are overriding the labels. It should/could
> prevent a trojan from passing the files out though - it would not be
> authorized access to the secret key(s) or the Kerberos ticket cache. Only
> trusted utilities would have that capability.

However if the ticket can't be used on other machines then the concern is not 
that it will be passed out, but that a process holding the ticked will be 
controlled by a program that is a proxy running on behalf of a program 
outside.

One of my friends wrote a nifty set of CGI scripts to run a terminal session 
through a web page using standard web forms functionality.  It wouldn't be 
THAT much more difficult to do it the other way around and have machine 
running bash be the HTTP client and the HTTP server have the client side of 
the shell session.

-- 
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 -- enabling user_r in eklogin

[Jesse Pollard]

On Thursday 19 December 2002 04:33 pm, Russell Coker wrote:
> On Thu, 19 Dec 2002 15:02, Jesse Pollard wrote:
> > > It's the same thing.  If I can trick you into running some arbitary
> > > commands with your main role then I can get your ssh identity key and
> > > your gpg secret key.  These crypto keys are often worth more than the
> > > hardware that they are stored on...
> >
> > Only if access is permitted to be over an unsecured channel.
> >
> > The differentation between a local user and a remote user has to be
> > provided.
>
> The "if I can trick you" part means that the distinction between local and
> remote logins is probably not relevant.  Consider that you meet someone in
> Starbucks and say "there's this really cool program at www.foo.com" which
> they then download and run...
>
> Of course we could deny execute access to user_home_t but variations on the
> same theme can always be used while there are users who can be tricked and
> net access for easy back-channels.
>
> > Access to the secret key(s) probably should not be permitted from an
> > unsecured location/connection. This does require network labels to work.
>
> I guess you could have different roles, and have sshd only allow
> transitioning to a low security role which is prohibited from running ssh
> or gpg.  I wonder whether a domain that only has full access to
> user_home_dir_t and user_home_t can misdirect the actions of ssh or gpg..

Only if ssh/gpg doesn't have the ability to distinguish between secure data 
and insecure data. It would seem reasonable (for some level of reasonable)
that gpg should be able to sign less secure data using a normally inaccessable
secret key, IF it can recognize that changing/generating keys is not allowed
(or perhaps it should, provided the keys are also marked at the lower level - 
multilevel filesystems are a bitch to debug)

> I don't think that network labels allow us to do anything productive in
> this regard as network operations are so abstracted.  When a KDE ioslave
> can talk to a http proxy to get access to the outside network then making
> real use of network labels without seriously reducing functionality is
> almost impossible.
>
> For my aims a significant reduction in functionality is unacceptable.

I haven't analyzed how KDE is functioning yet, but full functionality would 
still exist IF the application is communicating to a remote host/network that
can be trusted at the same level as the local system. As soon as it is
communicating with a less trusted media/medium then it really should start
being restricted.

If it is at a lower level, then yes, some functionality should be lost - 
though that should not be significant, PROVIDED the X server and KDE know how
to compartmentalize the facilities communicating with that less trusted 
service.

Note- things like multi-media applications should not really have that much
of a problem. The lowest level label used would be the data source. If the
other channels (local audio, video, and control interface) can provide multi
level capable controls, then a controled low level channel should be possible
for the audio/video output. The user would see no loss of functionality.

I realize that this is NOT a simple thing to do. It does require full 
compartemented workstation support.

> > It does mean that the plugin for checking PGP signatures (at a minimum
> > the one for generating signatures) would have to be sufficiently separate
> > from the netscape process to be labeled separately. It could not use
> > loadable modules, for  instance. It also means any scripts started should
> > not have access either.
>
> The problem is that if you can run GPG currently you can encrypt the secret
> key to yourself with a password (IE not encrypting to a public key) and
> then decrypt the result to get the key.  A future version of GPG will
> address this.  I don't know how PGP performs in this regard.

Yup. That is one of the things the application must be able to evaluate. The
output media/medium is the determining factor here. To do this requires 
reading data with a high level label by a trusted process which must NOT
write that data to a media/medum with a low level label. That trusted process
SHOULD be able to read low labeled data, munch it using high labled data,
and write it to a low labeled media/medum since this is WHY it is a trusted 
process.

Granted some attacks do become possible. The low level data might be null, 
permitting a potential brute force attack with a known text. There are likely
other forms of attack too. Most of these can be remedied by adding in a random
string to prevent null text. It would become more usable and more transparent
to the user that way.

> > This is not a 100% solution - If netscape is used to download an
> > application, then the user proceeds to configure/compile/run then all
> > bets are off since the users actions are overriding the labels. It
> > should/could prevent a trojan from passing the files out though - it
> > would not be authorized access to the secret key(s) or the Kerberos
> > ticket cache. Only trusted utilities would have that capability.
>
> However if the ticket can't be used on other machines then the concern is
> not that it will be passed out, but that a process holding the ticked will
> be controlled by a program that is a proxy running on behalf of a program
> outside.

correct. That requires the program that is trusted to be able to evaluate the
security environment before taking action.

> One of my friends wrote a nifty set of CGI scripts to run a terminal
> session through a web page using standard web forms functionality.  It
> wouldn't be THAT much more difficult to do it the other way around and have
> machine running bash be the HTTP client and the HTTP server have the client
> side of the shell session.

Yup - have seen that one too. The usual remedy for this is that the trusted 
application evaluates it's security environment. The pty is assigned the 
level of the CGI. If the CGI is less trusted by the server it should be run
at a low security level. That terminal session could then attempt to run a
trusted process. however, if that trusted process attempts to write/obtain the
secret key, then it would/should refuse since it cannot operate higher than 
it's environment, as defined by the terminal session.

Personally, I dislike the idea of privileged applications. For a secure 
environment, I would prever all secret keys to be maintained by a security
server process, and all queries/updates for access to this data to be carried
out by that security server. This would turn at least half of GPG/Kerberos 
functions over to the security server (which should pass the actions on the
keys to sub processes. That includes encryption/decryption services, though
the security server may just pass a socket connection back to the requesting
application to allow that application to push data into the encryption engine
and either recieve the results, or the output could already be connected to
another socket for outgoing data.

Complicated perhaps, but no trusted application need exist other than the 
security server. And the users would have no need to access the secret keys
directly.

Currently, the kerberos server side does exactly this - the untrusted remote
must authenticate to the server, once trust is established, the server
interposes an encryption server between the terminal session and the remote
encryption client. If this were split up as above, then the kerberized telnet
operation becomes equivalent to the old telnet process except:

1. the telnet client requests a connection to the remote server by passing the
    request to the security server.
2. the security server takes the security level of the request from the
    process requesting it
3. the outgoing connection is established by the security server and labeled
   at the requesting level. The remote security server can then request
   authentication by whatever means accepted to both
4. Assuming acceptance, the security server puts an encryption service (if
   required) between the client and the outgoing socket.
5. The remote security server would put another encryption service between the
    incoming socket and the application server, running at the same level as
    the incoming socket label.

It would then be up to the application server whether to create a terminal
session or other processing server. The security server on both systems would
be controlling access to any secret keys needed.

Connection "acceptance" would be negotiated via (in this case) a kerberos 
authenction, any ticket forwarding handling, required encryption services,
and label matching - would all be handled by the security server. It would
even permit different algorithms to be selected. Might use AES to one system,
3DES to another, or RSA/Blowfish/... whatever was agreed upon by the two
systems.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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 -- enabling user_r in eklogin

[Russell Coker]

On Fri, 20 Dec 2002 17:25, Jesse Pollard wrote:
> > I guess you could have different roles, and have sshd only allow
> > transitioning to a low security role which is prohibited from running ssh
> > or gpg.  I wonder whether a domain that only has full access to
> > user_home_dir_t and user_home_t can misdirect the actions of ssh or gpg..
>
> Only if ssh/gpg doesn't have the ability to distinguish between secure data
> and insecure data. It would seem reasonable (for some level of reasonable)
> that gpg should be able to sign less secure data using a normally
> inaccessable secret key, IF it can recognize that changing/generating keys
> is not allowed (or perhaps it should, provided the keys are also marked at
> the lower level - multilevel filesystems are a bitch to debug)

It seems reasonable to me that the main part of the ssh and gpg programs 
should be devoted to operating on behalf of the user rather than trying to 
enforce system policies.

If the sshd and gpg programs have to know about system security policies then 
I think that indicates that a bad approach is being taken to security.

The gpg people seem to like my idea of having a separate process that just 
reads the gpg secret key and pipes it back to the main application.  That 
allows me as a SE Linux policy author and every SE Linux administrator to 
have choices about how the security policy works that don't affect gpg 
compilation.  I don't think that the authors of such programs want to be 
worried about the issues we are discussing, and in the case of ssh I don't 
want to trust the authors for this.

> If it is at a lower level, then yes, some functionality should be lost -
> though that should not be significant, PROVIDED the X server and KDE know
> how to compartmentalize the facilities communicating with that less trusted
> service.

They don't.  This is something I would like to do.  I thought about giving a 
paper on this for OLS 2003, but at this stage I doubt I'll get it done in 
time.

Some of this coding is going to get really ugly.

> I realize that this is NOT a simple thing to do. It does require full
> compartemented workstation support.

To do it properly it does require CW support.  To do a half-job that will stop 
the majority of potential exploits SE Linux will do OK right now I think.

> > The problem is that if you can run GPG currently you can encrypt the
> > secret key to yourself with a password (IE not encrypting to a public
> > key) and then decrypt the result to get the key.  A future version of GPG
> > will address this.  I don't know how PGP performs in this regard.
>
> Yup. That is one of the things the application must be able to evaluate.
> The output media/medium is the determining factor here. To do this requires
> reading data with a high level label by a trusted process which must NOT
> write that data to a media/medum with a low level label. That trusted
> process SHOULD be able to read low labeled data, munch it using high labled
> data, and write it to a low labeled media/medum since this is WHY it is a
> trusted process.

Are you sure that it's a good idea to make gpg a trusted program that can 
over-ride MLS boundaries rather than have it merely be trusted to perform the 
actions that the user requests of it?

Currently we only have to trust that gpg will do what we tell it to.  The GPG 
developers plan to make some small changes to make it easier for me to ensure 
that gpg isn't executed in the wrong way by the wrong program.

If gpg has to become a trusted part of system security (as it is on default 
Linux systems due to being SUID root) then the requirements on gpg are much 
greater.  The counter arguement of course is that this level of trust in gpg 
apparently works OK on default Linux setups...

> Personally, I dislike the idea of privileged applications. For a secure
> environment, I would prever all secret keys to be maintained by a security
> server process, and all queries/updates for access to this data to be
> carried out by that security server. This would turn at least half of
> GPG/Kerberos functions over to the security server (which should pass the
> actions on the keys to sub processes. That includes encryption/decryption
> services, though the security server may just pass a socket connection back
> to the requesting application to allow that application to push data into
> the encryption engine and either recieve the results, or the output could
> already be connected to another socket for outgoing data.
>
> Complicated perhaps, but no trusted application need exist other than the
> security server. And the users would have no need to access the secret keys
> directly.

Interesting idea.  Sounds like kerberos on steroids.  ;)

-- 
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 -- enabling user_r in eklogin

[Jesse Pollard]

On Friday 20 December 2002 12:40 pm, Russell Coker wrote:
> On Fri, 20 Dec 2002 17:25, Jesse Pollard wrote:>
> > > The problem is that if you can run GPG currently you can encrypt the
> > > secret key to yourself with a password (IE not encrypting to a public
> > > key) and then decrypt the result to get the key.  A future version of
> > > GPG will address this.  I don't know how PGP performs in this regard.
> >
> > Yup. That is one of the things the application must be able to evaluate.
> > The output media/medium is the determining factor here. To do this
> > requires reading data with a high level label by a trusted process which
> > must NOT write that data to a media/medum with a low level label. That
> > trusted process SHOULD be able to read low labeled data, munch it using
> > high labled data, and write it to a low labeled media/medum since this is
> > WHY it is a trusted process.
>
> Are you sure that it's a good idea to make gpg a trusted program that can
> over-ride MLS boundaries rather than have it merely be trusted to perform
> the actions that the user requests of it?

Not all boundaries - only the one protecting the gpg secret key. You have to 
trust some program somewhere, and this one would seem to be the minimum.

> Currently we only have to trust that gpg will do what we tell it to.  The
> GPG developers plan to make some small changes to make it easier for me to
> ensure that gpg isn't executed in the wrong way by the wrong program.
>
> If gpg has to become a trusted part of system security (as it is on default
> Linux systems due to being SUID root) then the requirements on gpg are much
> greater.  The counter arguement of course is that this level of trust in
> gpg apparently works OK on default Linux setups...

And the one I suggested provides less trust than setuid.

The only modifications I can think of are that it would NOT allow the key to
be extracted IF it is providing output for a lower security level. I think it
would be desirable to allow it to USE the key (for encryption, decrypton, and
signing), but not allow the key itself to get out of the application, nor
allow the key to be replaced.

> > Personally, I dislike the idea of privileged applications. For a secure
> > environment, I would prever all secret keys to be maintained by a
> > security server process, and all queries/updates for access to this data
> > to be carried out by that security server. This would turn at least half
> > of GPG/Kerberos functions over to the security server (which should pass
> > the actions on the keys to sub processes. That includes
> > encryption/decryption services, though the security server may just pass
> > a socket connection back to the requesting application to allow that
> > application to push data into the encryption engine and either recieve
> > the results, or the output could already be connected to another socket
> > for outgoing data.
> >
> > Complicated perhaps, but no trusted application need exist other than the
> > security server. And the users would have no need to access the secret
> > keys directly.
>
> Interesting idea.  Sounds like kerberos on steroids.  ;)

yes - My original idea was to allow IPSec to handle the encryption, and the 
security server handle the keys, identfication, authentication, and initial
security labels. It makes most of the Kerberos utilities devolve into user 
interface, file/shell interface, and security server interaction. A much
simpler security environment when compaired to the amount of code
currently used in Kerberos.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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 -- enabling user_r in eklogin

[Russell Coker]

On Fri, 20 Dec 2002 21:07, Jesse Pollard wrote:
> > Are you sure that it's a good idea to make gpg a trusted program that can
> > over-ride MLS boundaries rather than have it merely be trusted to perform
> > the actions that the user requests of it?
>
> Not all boundaries - only the one protecting the gpg secret key. You have
> to trust some program somewhere, and this one would seem to be the minimum.

I probably should try out MLS.

> The only modifications I can think of are that it would NOT allow the key
> to be extracted IF it is providing output for a lower security level. I
> think it would be desirable to allow it to USE the key (for encryption,
> decrypton, and signing), but not allow the key itself to get out of the
> application, nor allow the key to be replaced.

OK.  This all sounds reasonable.  Are you planning to do some coding on it?

I have no plans to ever do any gpg coding...

-- 
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.