MLS enforcing PTYs, sshd, and newrole

MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

Hello,

in recent LSPP discussions, the subject of end-to-end enforcement of MLS
restrictions in a labeled networking environment came up again, and I had
volunteered to summarize it.

Here's the current situation as I understand it (please correct me if I
misunderstand it).

Background: A user who logs in via sshd over a labeled network connection
through xinetd will get a default MLS level assigned based on the
connection's level.  Then, when using newrole to change MLS levels,
newrole creates a PTY pair and relabels one end to the new level, while
the other end stays at the original level.

There's currently no effective enforcement of MLS restrictions between
the endpoints of a PTY pair, as described in the following bug:

     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200110

The effect is that the user could "cat" secret data and have it sent over
an "unclassified" network connection; or use "newrole" to easily
reclassify data without needing any MLS override privileges.

Adding MLS enforcement for PTYs is tricky. There are mainly two options
to give SELinux a chance to enforce rules and constraints:

(a) always relabel both ends synchronously and trust the existing
    MLS constraint checks to prevent unauthorized data flows

(b) do an MLS check in the middle of the PTY to ensure data flow is
    permitted between the ends

Option (a) doesn't work since sshd is a trusted application with MLS
overrides, so it'll happily ignore any MLS level mismatches on data
coming from the relabeled PTY end facing the network. 

Option (b) is also undesirable since it would either need to permit MLS
overrides based on the endpoint labels (which would bring back the sshd
override problem), or if it doesn't permit overrides it would be useless
for cases where you do want them.

Both options are currently not implemented and are likely to break
applications for people who don't care about meeting LSPP requirements,
which is obviously undesirable.

This was the basis for a fairly radical alternate proposal: Leave the PTY
behavior the way it is now, but make sure that they never get relabeled
so that the MLS check is unnecessary. That means no more "newrole -l".

So, an attempt to get a LSPP compliant configuration might look something
like the following (nobody is proposing making this the shipped default,
it would be set up locally by those who want it):

- don't allow non-admin users to run the newrole program at all, for
  example by setting its DAC rights to be root-executable only.

- for network login via sshd, nothing really changes. The user gets a
  session using the network connection's current context, and stays at
  that level for the entire session.

- local login always launches a session at the default context for the
  user

If you need local console (or serial) login at different MLS levels for
the same user, you can create multiple Linux users for each human user
that share the same uid and home directory, and use "semanage login" to
map them to appropriate levels. So you'd have smith_secret_cat1,
smith_unclassified and so on.

(That's currently not well compatible with polyinstantiation based on
username - it would be preferable to use the numerical UID (or canonical
username) instead of the login name for the polydir. But that would be a
fairly easy fix.)

It should still work to put a multilevel X desktop on top of this, since
that presumably uses a mechanism other than "newrole" to launch terminals
or windows at different levels. But that's only guesswork due to not
having seen any code for this...

Comments?

-Klaus

--
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: MLS enforcing PTYs, sshd, and newrole

[Russell Coker]

On Thursday 12 October 2006 17:33, Klaus Weidner <klaus@atsec.com> wrote:
> If you need local console (or serial) login at different MLS levels for
> the same user, you can create multiple Linux users for each human user
> that share the same uid and home directory, and use "semanage login" to
> map them to appropriate levels. So you'd have smith_secret_cat1,
> smith_unclassified and so on.

That doesn't work well with password expiry policies.  Having 
smith_secret_cat1 password expire at different times to smith_unclassified 
would be a pain for users and sys-admins.

Then if you want to use RSA SecurID or similar tokens you have an extra level 
of pain in mapping them to the right Unix account names.

I think that the right solution is to re-enable the code for selecting the 
role etc at login time and adding some code for selecting the level.  It 
should not be difficult to do this if there are no plans to ever support it 
for ssh or X logins.

> It should still work to put a multilevel X desktop on top of this, since
> that presumably uses a mechanism other than "newrole" to launch terminals
> or windows at different levels. But that's only guesswork due to not
> having seen any code for this...

Can someone who has worked on one of these things before please comment on how 
it's done?

It seems to me that the current way of managing desktops isn't going to work 
(IE Gnome and KDE won't work).

Currently we have a desktop manager program that can launch an xterm (in the 
same context) and then a shell (EG bash) is run in the same context as an 
xterm.  This means that if you run a hostile program in one xterm it can 
ptrace or otherwise interfere with all processes back to the desktop and down 
again to another xterm.  I guess we need to have a trusted desktop manager (I 
use the term loosely, such a program probably wouldn't have 10% the features 
of anything we currently call a "desktop manager") that launches xterms in 
different contexts depending on what they are doing and has the option of 
launching an xterm that runs "newrole -l" (or maybe launches xterms at 
different levels).

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

On Thu, Oct 12, 2006 at 08:25:12PM +1000, Russell Coker wrote:
> On Thursday 12 October 2006 17:33, Klaus Weidner <klaus@atsec.com> wrote:
> > If you need local console (or serial) login at different MLS levels for
> > the same user, you can create multiple Linux users for each human user
> > that share the same uid and home directory, and use "semanage login" to
> > map them to appropriate levels. So you'd have smith_secret_cat1,
> > smith_unclassified and so on.
> 
> That doesn't work well with password expiry policies.  Having 
> smith_secret_cat1 password expire at different times to smith_unclassified 
> would be a pain for users and sys-admins.
> 
> Then if you want to use RSA SecurID or similar tokens you have an extra level 
> of pain in mapping them to the right Unix account names.
> 
> I think that the right solution is to re-enable the code for selecting the 
> role etc at login time and adding some code for selecting the level.  It 
> should not be difficult to do this if there are no plans to ever support it 
> for ssh or X logins.

Good point, and I agree that the right long-term solution would be to
do context selection (via a PAM module?) at login time. 

I don't think that it's a significant issue though for current LSPP
configurations - any people who plan to use this please speak up if you
disagree.  The current LSPP configurations are for server systems, and
require that local consoles (including serial consoles listed in
/etc/securetty) are physically restricted to be accessible by admins
only, and admins can still use newrole. This leaves only non-admin serial
terminals, and I don't think those are that common these days.

Of course, people deploying a system that's based on the LSPP
configuration can choose to deviate from the evaluated configuration
based on their own risk assessment. This could include restoring general
access to "newrole" if they don't consider the PTY exploit to be a
concern.

-Klaus

--
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: MLS enforcing PTYs, sshd, and newrole

[Michael C Thompson]

Klaus Weidner wrote:
> Of course, people deploying a system that's based on the LSPP
> configuration can choose to deviate from the evaluated configuration
> based on their own risk assessment. This could include restoring general
> access to "newrole" if they don't consider the PTY exploit to be a
> concern.

And if you want polyinstation, then an suid newrole needs to be available :)


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- Klaus Weidner <klaus@atsec.com> wrote:


> I don't think that it's a significant issue though
> for current LSPP
> configurations - any people who plan to use this
> please speak up if you
> disagree.  The current LSPP configurations are for
> server systems,

A common deployment of an MLS system is the
the enormous compute "server", where users
log in at various MLS values to process
data, some of which is common, and some of
which is not. Usually this means a network
login, today typically using ssh. Rarely
will a user need to log in at more than one
MLS value, but it can (and has) happened
that a user will have multiple valid MLS
values. In some installations they will want
to allow this over "unlabeled networks",
and in some they will not.

> and
> require that local consoles (including serial
> consoles listed in
> /etc/securetty) are physically restricted to be
> accessible by admins
> only, and admins can still use newrole. This leaves
> only non-admin serial
> terminals, and I don't think those are that common
> these days.

Indeed!

> Of course, people deploying a system that's based on
> the LSPP
> configuration can choose to deviate from the
> evaluated configuration
> based on their own risk assessment. This could
> include restoring general
> access to "newrole" if they don't consider the PTY
> exploit to be a
> concern.

It might be best if you don't say that out loud.


Casey Schaufler
casey@schaufler-ca.com

--
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: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:

> On Thursday 12 October 2006 17:33, Klaus Weidner
> <klaus@atsec.com> wrote:
> > If you need local console (or serial) login at
> different MLS levels for
> > the same user, you can create multiple Linux users
> for each human user
> > that share the same uid and home directory, and
> use "semanage login" to
> > map them to appropriate levels. So you'd have
> smith_secret_cat1,
> > smith_unclassified and so on.

The Unix MLS systems provide mechanism
in login to specify MAC the user label.

In Trix 6 I would use:

    login: casey MAC=appropriatevalue
    passwd: ....

In Trix 4 it was:

    login: casey
    label: appropriatevalue
    passwd: ...

In Solaris I *think* it would be:

    login: casey -l appropriatevalue
    passwd: ...

but rust could well have filled that part
of my memory.

Creating a seperate login name for each MLS
value would be fine if you have a small number
of users with a small number of labels, but
will not be competitive in a production
environment.

> That doesn't work well with password expiry
> policies.  Having 
> smith_secret_cat1 password expire at different times
> to smith_unclassified 
> would be a pain for users and sys-admins.

That too.

> Then if you want to use RSA SecurID or similar
> tokens you have an extra level 
> of pain in mapping them to the right Unix account
> names.
> 
> I think that the right solution is to re-enable the
> code for selecting the 
> role etc at login time and adding some code for
> selecting the level.  It 
> should not be difficult to do this if there are no
> plans to ever support it 
> for ssh or X logins.
> 
> > It should still work to put a multilevel X desktop
> on top of this, since
> > that presumably uses a mechanism other than
> "newrole" to launch terminals
> > or windows at different levels. But that's only
> guesswork due to not
> > having seen any code for this...
> 
> Can someone who has worked on one of these things
> before please comment on how 
> it's done?

Hee Hee Hee. On Trix you get a new window at
a different label using su -M:

    trix% su -M moresecret -c xterm &
    trix% su -M evenmoresecret -c xclock &

This works because "su -M" closes all open
fds, reopening std{in,out,err} on /dev/null,
and the X server is MLS aware, accepting
connections with any label the user is cleared
for and enforcing policy on the objects it
controls. The X server uses TSIG interfaces
to obtain MLS information about the far end
of the connections ...

> It seems to me that the current way of managing
> desktops isn't going to work 
> (IE Gnome and KDE won't work).

... and the window manager is also MLS aware.



Casey Schaufler
casey@schaufler-ca.com

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

So one proposed solution to this is to take away the newrole -l 
functionality all together and to add Sensitivity selection to the local 
login. 

We can implement pam_selinux to ask for the sensitivity level


username: dwalsh
passwd: ********
Sensitivity: SystemLow

If we then remove -l from newrole we are done?

Dan

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2006-10-19 at 09:21 -0400, Daniel J Walsh wrote:
> So one proposed solution to this is to take away the newrole -l 
> functionality all together and to add Sensitivity selection to the local 
> login. 
> 
> We can implement pam_selinux to ask for the sensitivity level
> 
> 
> username: dwalsh
> passwd: ********
> Sensitivity: SystemLow
> 
> If we then remove -l from newrole we are done?

pam_selinux used to have support to let the user pick from the list of
reachable contexts for the user.  So you could just restore that
support.

That doesn't address sshd though.  Or gdm.  sshd shouldn't be too
difficult.  There were some externally developed gdm patches for selinux
that enabled context selection long ago, but nothing recent
(pre-Fedora).

You don't need to remove -l from newrole; you can just constrain its use
via DAC and via SELinux policy, as Klaus has previously suggested.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

Stephen Smalley wrote:
> On Thu, 2006-10-19 at 09:21 -0400, Daniel J Walsh wrote:
>   
>> So one proposed solution to this is to take away the newrole -l 
>> functionality all together and to add Sensitivity selection to the local 
>> login. 
>>
>> We can implement pam_selinux to ask for the sensitivity level
>>
>>
>> username: dwalsh
>> passwd: ********
>> Sensitivity: SystemLow
>>
>> If we then remove -l from newrole we are done?
>>     
>
> pam_selinux used to have support to let the user pick from the list of
> reachable contexts for the user.  So you could just restore that
> support.
>   
I don't think so.  This allowed you to select your TE role, not your 
Sensitivity.  The problem is selecting your sensivity.  Since there is 
an large number of sensitivities a user can log in as he will need to 
key it in.
> That doesn't address sshd though.  Or gdm.  sshd shouldn't be too
> difficult.  There were some externally developed gdm patches for selinux
> that enabled context selection long ago, but nothing recent
> (pre-Fedora).
>   
I though the sshd would happen automatically when you login via a secure 
channel.  IE If I connect at TopSecret, I get TopSecret.

I think gdm will require other features such that I launch terminals at 
different sensitivity levels???

I think we should separate the TE Context selection from the Sensitivity 
Selection, in order to satisfy the MLS problems.
> You don't need to remove -l from newrole; you can just constrain its use
> via DAC and via SELinux policy, as Klaus has previously suggested.
>
>   
So it will not work on ptys?  Or are you thinking a boolean? I think it 
will be strange for a user to have the app work differently depending on 
how they logged in, but I guess this is another short coming of MLS.


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2006-10-19 at 10:06 -0400, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > pam_selinux used to have support to let the user pick from the list of
> > reachable contexts for the user.  So you could just restore that
> > support.
> >   
> I don't think so.  This allowed you to select your TE role, not your 
> Sensitivity.  The problem is selecting your sensivity.  Since there is 
> an large number of sensitivities a user can log in as he will need to 
> key it in.

Ah, I was thinking of the old MLS implementation, pre-TCS.  Fair point.

> > That doesn't address sshd though.  Or gdm.  sshd shouldn't be too
> > difficult.  There were some externally developed gdm patches for selinux
> > that enabled context selection long ago, but nothing recent
> > (pre-Fedora).
> >   
> I though the sshd would happen automatically when you login via a secure 
> channel.  IE If I connect at TopSecret, I get TopSecret.

Only if running it via the modified xinetd and only if using labeled
networking.  Otherwise, you still need a way for users to select a level
for their session.

> I think gdm will require other features such that I launch terminals at 
> different sensitivity levels???

Well, doing that right requires security enhanced X, a modified window
manager, and a trusted path, so that won't be happening today.

> I think we should separate the TE Context selection from the Sensitivity 
> Selection, in order to satisfy the MLS problems.

Ok.

> > You don't need to remove -l from newrole; you can just constrain its use
> > via DAC and via SELinux policy, as Klaus has previously suggested.
> >
> >   
> So it will not work on ptys?  Or are you thinking a boolean? I think it 
> will be strange for a user to have the app work differently depending on 
> how they logged in, but I guess this is another short coming of MLS.

It would be restricted via DAC mode and possibly a boolean in policy,
such that an admin could allow use of it if desired.  Only the LSPP
config would need to lock it down.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> ...  Since there is 
> an large number of sensitivities a user can log in
> as he will need to 
> key it in.

Existing systems allow the user a default MLS
value that is used (on a terminal) if none is
specified (e.g. just hit ENTER at the label
prompt).


> I though the sshd would happen automatically when
> you login via a secure 
> channel.  IE If I connect at TopSecret, I get
> TopSecret.

This is the usual behavior, but we're talking
about real deployments here, so there will
always be someone who wants (and is unwilling
to use/buy a system that won't allow her) to
long in at multiple labels across a single
level network. For your system to be popular
you need to provide the facility. Just consider
the admin who wants to log in at SystemHigh
to fix the broken network.

> I think gdm will require other features such that I
> launch terminals at 
> different sensitivity levels???
> 
> I think we should separate the TE Context selection
> from the Sensitivity 
> Selection, in order to satisfy the MLS problems.

>From the standpoint of someone who likes MLS
better than TE, I agree, but from the standpoint
of someone who hates to see mixed metaphores
I disagree.


> So it will not work on ptys?  Or are you thinking a
> boolean? I think it 
> will be strange for a user to have the app work
> differently depending on 
> how they logged in, but I guess this is another
> short coming of MLS.

I don't get how this is a shortcoming of MLS.


Casey Schaufler
casey@schaufler-ca.com

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley wrote:

> pam_selinux used to have support to let the user pick from the list of
> reachable contexts for the user.  So you could just restore that
> support.

 So, in summary of the discussion, having pam_selinux let the user pick
the TE and Sensitivity separately (much as it does now if
get_ordered_context_list_with_level() fails) is the valid approach?

> That doesn't address sshd though.  Or gdm.  sshd shouldn't be too
> difficult.

 Combined with adding similar code to sshd.

>   There were some externally developed gdm patches for selinux
> that enabled context selection long ago, but nothing recent
> (pre-Fedora).

 But, from the "gdm/trsuted-X needs lots more work" discussion, gdm
should just stay with the default Sensitivity and people can use a
terminal+ssh to change levels?

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- James Antill <jantill@redhat.com> wrote:

> On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley
> wrote:
> 
> > pam_selinux used to have support to let the user
> pick from the list of
> > reachable contexts for the user.  So you could
> just restore that
> > support.
> 
>  So, in summary of the discussion, having
> pam_selinux let the user pick
> the TE and Sensitivity separately (much as it does
> now if
> get_ordered_context_list_with_level() fails) is the
> valid approach?

On Trix you can specify the MAC and Capabilities
this way, so it seems you ought to be able to
specify Sensitivity and TE on SELinux.

> > That doesn't address sshd though.  Or gdm.  sshd
> shouldn't be too
> > difficult.
> 
>  Combined with adding similar code to sshd.

Just a heads up, you want to do this, but
you may not be able to get an evaluation team
to allow it in an evaluated configuration.

> >   There were some externally developed gdm patches
> for selinux
> > that enabled context selection long ago, but
> nothing recent
> > (pre-Fedora).
> 
>  But, from the "gdm/trsuted-X needs lots more work"
> discussion, gdm
> should just stay with the default Sensitivity and
> people can use a
> terminal+ssh to change levels?

The MLS-ignorant Xserver should not be able to
communicate with clients run with a different MLS
value, but this trick ought to work, providing
further assurance that allowing the option to
specific MLS value when you login (ssh) over a
network connection won't get past the evaluators.
Plus, it will only work for terminals, not
for launching X clients.



Casey Schaufler
casey@schaufler-ca.com

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Paul Moore]

Casey Schaufler wrote:
> 
> --- James Antill <jantill@redhat.com> wrote:
> 
>>On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley
>>wrote:
>> 
>>>That doesn't address sshd though.  Or gdm.  sshd
>>shouldn't be too difficult.
>>
>> Combined with adding similar code to sshd.
> 
> 
> Just a heads up, you want to do this, but
> you may not be able to get an evaluation team
> to allow it in an evaluated configuration.

Okay, I'm curious so I'll bite - why not, what problems would you expect?

-- 
paul moore
linux security @ hp

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> Casey Schaufler wrote:
> > 
> > --- James Antill <jantill@redhat.com> wrote:
> > 
> >>On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley
> >>wrote:
> >> 
> >>>That doesn't address sshd though.  Or gdm.  sshd
> >>shouldn't be too difficult.
> >>
> >> Combined with adding similar code to sshd.
> > 
> > 
> > Just a heads up, you want to do this, but
> > you may not be able to get an evaluation team
> > to allow it in an evaluated configuration.
> 
> Okay, I'm curious so I'll bite - why not, what
> problems would you expect?

I'm talking strictly from an MLS viewpoint here,
mind you. If y'all are using TE as a security
mechanism in your evaluation you'll have to
deal with that as well. Anywho ...

If you are treating your network as a single
level device and allow logins (e.g. via ssh)
at labels other than that configured to the
device you are violating the MLS policy on
the device. A TopSecret login on a device
configured to be Confidential can not be
permitted because TopSecret information,
such as the command prompt, cannot be sent
to the Confidential device.

If you are treating the network as a multi
level device the communications will take
place at a label passed along with (or beside)
the packets. Changing the label of the process
will prevent it from going out through the
established connection. If you could, you'd
be able to pass TopSecret information in
packets marked Confidential, again a Bad Thing.

If you are treating each packet as a labeled
entity and the network environment irrelivent
and you don't change how the packets are labeled
when you change the process label you are not
properly labeling them. If you do change the
labeling of the packets and let them through
anyway you're not enforcing MLS policy.

You can treat the network as a device, an import/
export mechanism, or an internal communication
mechanism but you can't get away from the fact
that when a process changes its MLS properties
it can't use the communication channels it was
using with the old properties. Unless the
communication channels don't enforce policy,
in which case your system isn't enforcing
MLS policy everywhere required.

I understand that this is not the case with TE.
I am very curious how domain transitions are
going to play out in an evaluation. The process
should be educational.


Casey Schaufler
casey@schaufler-ca.com

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Mon, 2006-10-23 at 12:14 -0400, James Antill wrote:
> On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley wrote:
> > pam_selinux used to have support to let the user pick from the list of
> > reachable contexts for the user.  So you could just restore that
> > support.
>
>  So, in summary of the discussion, having pam_selinux let the user pick
> the TE and Sensitivity separately (much as it does now if
> get_ordered_context_list_with_level() fails) is the valid approach?

 Ok, I've done a patch to PAM which which adds a config_role option to
the pam_selinux module ... which if turned on takes the users default
context and allows them to change the role and/or level (if mls is
enabled). Entering a blank line sticks with the default.

 It's available from:

http://people.redhat.com/jantill/pam-config_role/

...the rpms there have been built on FC5.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[George C. Wilson]

On Tue, Oct 24, 2006 at 04:37:16PM -0400, James Antill wrote:
> On Mon, 2006-10-23 at 12:14 -0400, James Antill wrote:
> > On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley wrote:
> > > pam_selinux used to have support to let the user pick from the list of
> > > reachable contexts for the user.  So you could just restore that
> > > support.
> >
> >  So, in summary of the discussion, having pam_selinux let the user pick
> > the TE and Sensitivity separately (much as it does now if
> > get_ordered_context_list_with_level() fails) is the valid approach?
> 
>  Ok, I've done a patch to PAM which which adds a config_role option to
> the pam_selinux module ... which if turned on takes the users default
> context and allows them to change the role and/or level (if mls is
> enabled). Entering a blank line sticks with the default.
> 
>  It's available from:
> 
> http://people.redhat.com/jantill/pam-config_role/
> 
> ...the rpms there have been built on FC5.
> 

Thanks, James.  I got it built on a ppc64 victim.  Hopefully Klaus can take a
quick look to see if it will work for the cert.

-- 
George Wilson <ltcgcw@us.ibm.com>
IBM Linux Technology Center

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Tue, 2006-10-24 at 16:37 -0400, James Antill wrote:
> On Mon, 2006-10-23 at 12:14 -0400, James Antill wrote:
> > On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley wrote:
> > > pam_selinux used to have support to let the user pick from the list of
> > > reachable contexts for the user.  So you could just restore that
> > > support.
> >
> >  So, in summary of the discussion, having pam_selinux let the user pick
> > the TE and Sensitivity separately (much as it does now if
> > get_ordered_context_list_with_level() fails) is the valid approach?
> 
>  Ok, I've done a patch to PAM which which adds a config_role option to
> the pam_selinux module ... which if turned on takes the users default
> context and allows them to change the role and/or level (if mls is
> enabled). Entering a blank line sticks with the default.
> 
>  It's available from:
> 
> http://people.redhat.com/jantill/pam-config_role/
> 
> ...the rpms there have been built on FC5.

Doesn't this provide a way of bypassing the per-Linux-user level
restrictions defined by the seusers mapping (vs. per-SELinux-user)?

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Wed, 2006-10-25 at 07:48 -0400, Stephen Smalley wrote:
> On Tue, 2006-10-24 at 16:37 -0400, James Antill wrote:
> > On Mon, 2006-10-23 at 12:14 -0400, James Antill wrote:
> > > On Thu, 2006-10-19 at 09:30 -0400, Stephen Smalley wrote:
> > > > pam_selinux used to have support to let the user pick from the list of
> > > > reachable contexts for the user.  So you could just restore that
> > > > support.
> > >
> > >  So, in summary of the discussion, having pam_selinux let the user pick
> > > the TE and Sensitivity separately (much as it does now if
> > > get_ordered_context_list_with_level() fails) is the valid approach?
> > 
> >  Ok, I've done a patch to PAM which which adds a config_role option to
> > the pam_selinux module ... which if turned on takes the users default
> > context and allows them to change the role and/or level (if mls is
> > enabled). Entering a blank line sticks with the default.
> > 
> >  It's available from:
> > 
> > http://people.redhat.com/jantill/pam-config_role/
> > 
> > ...the rpms there have been built on FC5.
> 
> Doesn't this provide a way of bypassing the per-Linux-user level
> restrictions defined by the seusers mapping (vs. per-SELinux-user)?

To elaborate, as I understood it, seusers (managed via semanage login)
was to provide per-Linux-user authorizations for MLS/MCS ranges, while
multiple such Linux users might be mapped to a single SELinux user that
was authorized for the full system range.  The login-style programs
would then ensure that the range in the initial security context for the
Linux user's session was limited by the value defined in seusers, and
SELinux policy would subsequently ensure that processes in that session
can not escalate outside of that range via newrole -l (or other
mechanism).

It isn't sufficient to check the validity of the context with the
user-supplied level, because from the kernel's POV, any level might be
authorized for the underlying SELinux user identity, whereas seusers
might have defined a more restricted range for the Linux user identity.
You need a check between the user-supplied level and the seusers-defined
value (more generally, this could be an avc_has_perm or
security_compute_av check between contexts containing those levels, and
the underlying policy could define a mlsconstrain on the corresponding
permission). 

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Wed, 2006-10-25 at 08:22 -0400, Stephen Smalley wrote:

> To elaborate, as I understood it, seusers (managed via semanage login)
> was to provide per-Linux-user authorizations for MLS/MCS ranges, while
> multiple such Linux users might be mapped to a single SELinux user that
> was authorized for the full system range.  The login-style programs
> would then ensure that the range in the initial security context for the
> Linux user's session was limited by the value defined in seusers, and
> SELinux policy would subsequently ensure that processes in that session
> can not escalate outside of that range via newrole -l (or other
> mechanism).

 My understanding is that while security_check_context() allows it, the
setexeccon() will fail. Which seemed to be good enough.

> It isn't sufficient to check the validity of the context with the
> user-supplied level, because from the kernel's POV, any level might be
> authorized for the underlying SELinux user identity, whereas seusers
> might have defined a more restricted range for the Linux user identity.
> You need a check between the user-supplied level and the seusers-defined
> value (more generally, this could be an avc_has_perm or
> security_compute_av check between contexts containing those levels, and
> the underlying policy could define a mlsconstrain on the corresponding
> permission). 

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> On Wed, 2006-10-25 at 08:22 -0400, Stephen Smalley wrote:
> 
> > To elaborate, as I understood it, seusers (managed via semanage login)
> > was to provide per-Linux-user authorizations for MLS/MCS ranges, while
> > multiple such Linux users might be mapped to a single SELinux user that
> > was authorized for the full system range.  The login-style programs
> > would then ensure that the range in the initial security context for the
> > Linux user's session was limited by the value defined in seusers, and
> > SELinux policy would subsequently ensure that processes in that session
> > can not escalate outside of that range via newrole -l (or other
> > mechanism).
> 
>  My understanding is that while security_check_context() allows it, the
> setexeccon() will fail. Which seemed to be good enough.

No, it won't.  Suppose that I have two Linux users A and B, with A
authorized for category c0 and B authorized for category c2 in seusers,
but both A and B are mapped to SELinux user U who is authorized for all
categories in the kernel policy.  The login-style programs are naturally
going to be authorized to transition to any of those contexts since they
have to deal with user logins at any level, so the setexeccon() will
succeed.  The SELinux security context will have U as the user identity,
so it will always be valid.  You need an explicit check.

> 
> > It isn't sufficient to check the validity of the context with the
> > user-supplied level, because from the kernel's POV, any level might be
> > authorized for the underlying SELinux user identity, whereas seusers
> > might have defined a more restricted range for the Linux user identity.
> > You need a check between the user-supplied level and the seusers-defined
> > value (more generally, this could be an avc_has_perm or
> > security_compute_av check between contexts containing those levels, and
> > the underlying policy could define a mlsconstrain on the corresponding
> > permission). 
> 
-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Wed, 2006-10-25 at 09:59 -0400, Stephen Smalley wrote:
> On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> >  My understanding is that while security_check_context() allows it, the
> > setexeccon() will fail. Which seemed to be good enough.
> 
> No, it won't.  Suppose that I have two Linux users A and B, with A
> authorized for category c0 and B authorized for category c2 in seusers,
> but both A and B are mapped to SELinux user U who is authorized for all
> categories in the kernel policy.  The login-style programs are naturally
> going to be authorized to transition to any of those contexts since they
> have to deal with user logins at any level, so the setexeccon() will
> succeed.  The SELinux security context will have U as the user identity,
> so it will always be valid.  You need an explicit check.

 Ok, I had assumed that "U" would always be different in this case. I
think this update to the patch solves the problem ... it gets the list
of valid roles/levels from get_ordered_context_list() (which I think is
complete, but I'm not 100%) and compares what is entered against that.
 I'm not 100% sure this is right (it means there would be huge lists
returned for MCS, no?), but I don't see what else I can call that would
validate the role/level-range for a specific login.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Wed, 2006-10-25 at 15:15 -0400, James Antill wrote:
> On Wed, 2006-10-25 at 09:59 -0400, Stephen Smalley wrote:
> > On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> > >  My understanding is that while security_check_context() allows it, the
> > > setexeccon() will fail. Which seemed to be good enough.
> > 
> > No, it won't.  Suppose that I have two Linux users A and B, with A
> > authorized for category c0 and B authorized for category c2 in seusers,
> > but both A and B are mapped to SELinux user U who is authorized for all
> > categories in the kernel policy.  The login-style programs are naturally
> > going to be authorized to transition to any of those contexts since they
> > have to deal with user logins at any level, so the setexeccon() will
> > succeed.  The SELinux security context will have U as the user identity,
> > so it will always be valid.  You need an explicit check.
> 
>  Ok, I had assumed that "U" would always be different in this case. I
> think this update to the patch solves the problem ... it gets the list
> of valid roles/levels from get_ordered_context_list() (which I think is
> complete, but I'm not 100%) and compares what is entered against that.
>  I'm not 100% sure this is right (it means there would be huge lists
> returned for MCS, no?), but I don't see what else I can call that would
> validate the role/level-range for a specific login.

Sorry, no (at least based on that description - didn't receive the patch
itself).  get_ordered_context_list() et al are still interfaces based on
SELinux user identity.  What you need to do is to validate the
user-supplied level against the range returned by getseuserbyname(), and
the particular check needs to see whether the level is within the user's
authorized range.  Which gets into policy specifics, which is why I
suggested using a permission check via avc_has_perm or
security_compute_av, and letting policy define a mlsconstrain on it.

-- 
Stephen Smalley
National Security Agency


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

[PATCH 1/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 610 bytes --]

On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:

> Look at Darrel's patch for mcstransd to apply a permission check between
> the level of the caller and the level being translated for context
> translations. 

 Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
this correct now.

 Here is the libselinux part of the patch (reference policy and PAM are
next).

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #1.2: selinux-pam-range-checking.patch --]
[-- Type: text/x-patch, Size: 991 bytes --]

Index: libselinux/include/selinux/av_permissions.h
===================================================================
--- libselinux/include/selinux/av_permissions.h	(revision 2074)
+++ libselinux/include/selinux/av_permissions.h	(working copy)
@@ -896,3 +896,4 @@
 #define KEY__SETATTR                              0x00000020UL
 #define KEY__CREATE                               0x00000040UL
 #define CONTEXT__TRANSLATE                        0x00000001UL
+#define CONTEXT__TRANSITION                       0x00000002UL
Index: libselinux/src/av_perm_to_string.h
===================================================================
--- libselinux/src/av_perm_to_string.h	(revision 2074)
+++ libselinux/src/av_perm_to_string.h	(working copy)
@@ -266,3 +266,4 @@
     S_(SECCLASS_KEY, KEY__SETATTR, "setattr")
     S_(SECCLASS_KEY, KEY__CREATE, "create")
     S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
+    S_(SECCLASS_CONTEXT, CONTEXT__TRANSITION, "transition")

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 703 bytes --]

On Mon, 2006-10-30 at 15:03 -0500, James Antill wrote:
> On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:
> 
> > Look at Darrel's patch for mcstransd to apply a permission check between
> > the level of the caller and the level being translated for context
> > translations. 
> 
>  Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
> this correct now.


 Here is the reference policy part of the patches (libselinux came
previously and PAM is next).


-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #1.2: policy-pam-range-checking.patch --]
[-- Type: text/x-patch, Size: 1074 bytes --]

Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2065)
+++ policy/flask/access_vectors	(working copy)
@@ -635,4 +635,5 @@
 class context
 {
 	translate
+	transition
 }
Index: policy/modules/system/authlogin.if
===================================================================
--- policy/modules/system/authlogin.if	(revision 2065)
+++ policy/modules/system/authlogin.if	(working copy)
@@ -278,6 +278,9 @@
 	allow $2 $1:fd use;
 	allow $2 $1:fifo_file rw_file_perms;
 	allow $2 $1:process sigchld;
+
+        # Check MLS Range
+        allow $1 domain:context transition;
 ')
 
 ########################################
Index: policy/mls
===================================================================
--- policy/mls	(revision 2065)
+++ policy/mls	(working copy)
@@ -596,4 +596,7 @@
 mlsconstrain context translate
 	(( h1 dom h2 ) or ( t1 == mlstranslate ));
 
+mlsconstrain context transition
+	( h1 dom h2 );
+
 ') dnl end enable_mls

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 3/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 639 bytes --]

On Mon, 2006-10-30 at 15:16 -0500, James Antill wrote:
> On Mon, 2006-10-30 at 15:03 -0500, James Antill wrote:
> > On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:
> > 
> > > Look at Darrel's patch for mcstransd to apply a permission check between
> > > the level of the caller and the level being translated for context
> > > translations. 
> > 
> >  Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
> > this correct now.


 Here is the PAM part of the patches (libselinux and reference policy
came previously). This requires the libselinux changes.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #1.2: pam-0.99.6.2-selinux-config_role.patch --]
[-- Type: text/x-patch, Size: 8715 bytes --]

diff -rup Linux-PAM-0.99.6.2-orig/modules/pam_selinux/pam_selinux.8.xml Linux-PAM-0.99.6.2/modules/pam_selinux/pam_selinux.8.xml
--- Linux-PAM-0.99.6.2-orig/modules/pam_selinux/pam_selinux.8.xml	2006-10-23 00:25:53.000000000 -0400
+++ Linux-PAM-0.99.6.2/modules/pam_selinux/pam_selinux.8.xml	2006-10-27 12:49:05.000000000 -0400
@@ -36,6 +36,9 @@
       <arg choice="opt">
 	verbose
       </arg>
+      <arg choice="opt">
+	config_role
+      </arg>
     </cmdsynopsis>
   </refsynopsisdiv>
 
@@ -121,6 +124,17 @@
           </para>
         </listitem>
       </varlistentry>
+      <varlistentry>
+        <term>
+          <option>config_role</option>
+        </term>
+        <listitem>
+          <para>
+            attempt to ask the user for a custom security context role (and
+            level, if MLS is on).
+          </para>
+        </listitem>
+      </varlistentry>
     </variablelist>
   </refsect1>
 
Only in Linux-PAM-0.99.6.2/modules/pam_selinux: pam_selinux.8.xml.config_role
diff -rup Linux-PAM-0.99.6.2-orig/modules/pam_selinux/pam_selinux.c Linux-PAM-0.99.6.2/modules/pam_selinux/pam_selinux.c
--- Linux-PAM-0.99.6.2-orig/modules/pam_selinux/pam_selinux.c	2006-10-23 00:25:53.000000000 -0400
+++ Linux-PAM-0.99.6.2/modules/pam_selinux/pam_selinux.c	2006-10-30 15:20:28.000000000 -0500
@@ -63,6 +63,7 @@
 #include <selinux/selinux.h>
 #include <selinux/get_context_list.h>
 #include <selinux/flask.h>
+#include <selinux/av_permissions.h>
 #include <selinux/selinux.h>
 #include <selinux/context.h>
 
@@ -151,6 +152,8 @@ manual_context (pam_handle_t *pamh, cons
 	}
 	else
 	  send_text(pamh,_("Not a valid security context"),debug);
+
+        context_free (new_context); /* next time around allocates another */
       }
     else {
       _pam_drop(responses);
@@ -161,6 +164,90 @@ manual_context (pam_handle_t *pamh, cons
   return NULL;
 }
 
+static int mls_range_allowed(security_context_t src, security_context_t dst)
+{
+  struct av_decision avd;
+  int retval;
+  int bit = CONTEXT__TRANSITION;
+  
+  retval = security_compute_av(src, dst, SECCLASS_CONTEXT, bit, &avd);
+  if (retval || ((bit & avd.allowed) != bit))
+    return 0;
+  
+  return 1;
+}
+
+static security_context_t
+config_context (pam_handle_t *pamh, security_context_t puser_context, int debug)
+{
+  security_context_t newcon;
+  context_t new_context;
+  int mls_enabled = is_selinux_mls_enabled();
+  char *responses;
+  char resp_val = 0;
+  
+  while (1) {
+    query_response(pamh,
+		   _("Would you like to enter a role/level? [y] "),
+		   &responses,debug);
+
+    resp_val = responses[0];
+    _pam_drop(responses);
+    if ((resp_val == 'y') || (resp_val == 'Y') || (resp_val == '\0'))
+      {
+        new_context = context_new (puser_context);
+        
+	/* Allow the user to enter role and level individually */
+	query_response(pamh,_("role: "),&responses,debug);
+	if (responses[0] && context_role_set (new_context, responses))
+              goto fail_set;
+	_pam_drop(responses);
+	if (mls_enabled)
+	  {
+	    query_response(pamh,_("level: "),&responses,debug);
+	    if (responses[0] && context_range_set (new_context, responses))
+              goto fail_set;
+	    _pam_drop(responses);
+	  }
+
+        /* Get the string value of the context and see if it is valid. */
+        if (!security_check_context(context_str(new_context))) {
+	  newcon = strdup(context_str(new_context));
+	  context_free (new_context);
+
+          /* we have to check that this user is allowed to go into the
+             range they have specified ... role is tied to an seuser, so that'll
+             be checked at setexeccon time */
+          if (mls_enabled && !mls_range_allowed(puser_context, newcon))
+            goto fail_range;
+
+          freecon(puser_context);
+	  return newcon;
+	}
+	else
+	  send_text(pamh,_("Not a valid security context"),debug);
+
+        context_free (new_context); /* next time around allocates another */
+      }
+    else
+      break;
+  } /* end while */
+
+  while (num-- > 0)
+    context_free(clist[num]);
+  free(clist);
+  
+  freecon(puser_context);
+  return NULL;
+
+ fail_set:
+  _pam_drop(responses);
+ fail_range:
+  context_free (new_context);
+  freecon(puser_context);
+  return NULL;  
+}
+
 static void
 security_restorelabel_tty(const pam_handle_t *pamh,
 			  const char *tty, security_context_t context)
@@ -273,10 +360,12 @@ pam_sm_open_session(pam_handle_t *pamh, 
 {
   int i, debug = 0, ttys=1, has_tty=isatty(0);
   int verbose=0, close_session=0;
+  int config_role = 0;
   int ret = 0;
   security_context_t* contextlist = NULL;
   int num_contexts = 0;
-  const void *username = NULL;
+  const void *pusername = NULL;
+  const char *username = NULL;
   const void *tty = NULL;
   char *seuser=NULL;
   char *level=NULL;
@@ -295,6 +384,12 @@ pam_sm_open_session(pam_handle_t *pamh, 
     if (strcmp(argv[i], "close") == 0) {
       close_session = 1;
     }
+    if (strcmp(argv[i], "config_role") == 0) {
+      config_role = 1;
+    }
+    if (strcmp(argv[i], "config_mls") == 0) {
+      config_role = 1;
+    }
   }
 
   if (debug)
@@ -307,10 +402,11 @@ pam_sm_open_session(pam_handle_t *pamh, 
   if (!(selinux_enabled = is_selinux_enabled()>0) )
       return PAM_SUCCESS;
 
-  if (pam_get_item(pamh, PAM_USER, &username) != PAM_SUCCESS ||
-                   username == NULL) {
+  if (pam_get_item(pamh, PAM_USER, &pusername) != PAM_SUCCESS ||
+                   pusername == NULL) {
     return PAM_USER_UNKNOWN;
   }
+  username = pusername;
 
   if (getseuserbyname(username, &seuser, &level)==0) {
 	  num_contexts = get_ordered_context_list_with_level(seuser, 
@@ -319,19 +415,32 @@ pam_sm_open_session(pam_handle_t *pamh, 
 							     &contextlist);
 	  if (debug)
 		  pam_syslog(pamh, LOG_DEBUG, "Username= %s SELinux User = %s Level= %s",
-			 (const char *)username, seuser, level);
+                             username, seuser, level);
 	  free(seuser);
 	  free(level);
   }
   if (num_contexts > 0) {
     user_context = (security_context_t) strdup(contextlist[0]);
+
+    if (config_role && has_tty) {
+      user_context = config_context(pamh, user_context, debug);
+      if (user_context == NULL) {
+	pam_syslog (pamh, LOG_ERR, "Unable to get valid context for %s",
+		    username);
+        if (security_getenforce() == 1)
+          return PAM_AUTH_ERR;
+        else
+          return PAM_SUCCESS;
+      }
+    }
+    
     freeconary(contextlist);
   } else {
     if (has_tty) {
       user_context = manual_context(pamh,username,debug);
       if (user_context == NULL) {
 	pam_syslog (pamh, LOG_ERR, "Unable to get valid context for %s",
-		    (const char *)username);
+		    username);
         if (security_getenforce() == 1)
           return PAM_AUTH_ERR;
         else
@@ -340,7 +449,7 @@ pam_sm_open_session(pam_handle_t *pamh, 
     } else {
         pam_syslog (pamh, LOG_ERR,
 		    "Unable to get valid context for %s, No valid tty",
-		    (const char *)username);
+		    username);
         if (security_getenforce() == 1)
           return PAM_AUTH_ERR;
         else
@@ -381,7 +490,7 @@ pam_sm_open_session(pam_handle_t *pamh, 
   if (ret) {
     pam_syslog(pamh, LOG_ERR,
 	       "Error!  Unable to set %s executable context %s.",
-	       (const char *)username, user_context);
+	       username, user_context);
     if (security_getenforce() == 1) {
        freecon(user_context);
        return PAM_AUTH_ERR;
@@ -389,7 +498,7 @@ pam_sm_open_session(pam_handle_t *pamh, 
   } else {
     if (debug)
       pam_syslog(pamh, LOG_NOTICE, "set %s security context to %s",
-		 (const char *)username, user_context);
+		 username, user_context);
   }
 #ifdef HAVE_SETKEYCREATECON
   ret = setkeycreatecon(user_context);
@@ -402,7 +511,7 @@ pam_sm_open_session(pam_handle_t *pamh, 
   if (ret) {
     pam_syslog(pamh, LOG_ERR,
 	       "Error!  Unable to set %s key creation context %s.",
-	       (const char *)username, user_context);
+	       username, user_context);
     if (security_getenforce() == 1) {
        freecon(user_context);
        return PAM_AUTH_ERR;
@@ -410,7 +519,7 @@ pam_sm_open_session(pam_handle_t *pamh, 
   } else {
     if (debug)
       pam_syslog(pamh, LOG_NOTICE, "set %s key creation context to %s",
-		 (const char *)username, user_context);
+		 username, user_context);
   }
 #endif
   freecon(user_context);
Only in Linux-PAM-0.99.6.2/modules/pam_selinux: pam_selinux.c.config_role

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Mon, 2006-10-30 at 15:16 -0500, James Antill wrote:
> On Mon, 2006-10-30 at 15:03 -0500, James Antill wrote:
> > On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:
> > 
> > > Look at Darrel's patch for mcstransd to apply a permission check between
> > > the level of the caller and the level being translated for context
> > > translations. 
> > 
> >  Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
> > this correct now.
> 
> 
>  Here is the reference policy part of the patches (libselinux came
> previously and PAM is next).

In addition to the permission name, I'd have expected the rule (and the
check in the code) to always use the same type in both contexts, so the
rules could just be:
	allow $1 self:context <permissionname>;

Not allow $1 domain:context, which will yield many more rules without
any real justification.

-- 
Stephen Smalley
National Security Agency


--
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: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Tue, 2006-10-31 at 09:23 -0500, Stephen Smalley wrote:
> On Mon, 2006-10-30 at 15:16 -0500, James Antill wrote:
> > On Mon, 2006-10-30 at 15:03 -0500, James Antill wrote:
> > > On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:
> > > 
> > > > Look at Darrel's patch for mcstransd to apply a permission check between
> > > > the level of the caller and the level being translated for context
> > > > translations. 
> > > 
> > >  Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
> > > this correct now.
> > 
> > 
> >  Here is the reference policy part of the patches (libselinux came
> > previously and PAM is next).
> 
> In addition to the permission name, I'd have expected the rule (and the
> check in the code) to always use the same type in both contexts, so the
> rules could just be:
> 	allow $1 self:context <permissionname>;
> 
> Not allow $1 domain:context, which will yield many more rules without
> any real justification.

I'm also unclear as to what you are checking - you seem to be putting
this in authlogin, but I had expected this to be a check between two
user contexts, identical in all respects except for the MLS ranges (one
from seusers, one from the user-supplied input).

-- 
Stephen Smalley
National Security Agency


--
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: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Tue, 2006-10-31 at 09:24 -0500, Stephen Smalley wrote:
> On Tue, 2006-10-31 at 09:23 -0500, Stephen Smalley wrote:
> > 
> > In addition to the permission name, I'd have expected the rule (and the
> > check in the code) to always use the same type in both contexts, so the
> > rules could just be:
> > 	allow $1 self:context <permissionname>;
> > 
> > Not allow $1 domain:context, which will yield many more rules without
> > any real justification.

 Ok, I can fix that to be just self:context.

> I'm also unclear as to what you are checking - you seem to be putting
> this in authlogin, but I had expected this to be a check between two
> user contexts, identical in all respects except for the MLS ranges (one
> from seusers, one from the user-supplied input).

 AIUI the code in authlogin allows all of the login type programs (like
getty) to call the check. The check being performed is in policy/mls and
is just:

mlsconstrain context transition
       ( h1 dom h2 );

...have I misunderstood this?

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Tue, 2006-10-31 at 10:00 -0500, James Antill wrote:
> On Tue, 2006-10-31 at 09:24 -0500, Stephen Smalley wrote:
> > On Tue, 2006-10-31 at 09:23 -0500, Stephen Smalley wrote:
> > > 
> > > In addition to the permission name, I'd have expected the rule (and the
> > > check in the code) to always use the same type in both contexts, so the
> > > rules could just be:
> > > 	allow $1 self:context <permissionname>;
> > > 
> > > Not allow $1 domain:context, which will yield many more rules without
> > > any real justification.
> 
>  Ok, I can fix that to be just self:context.
> 
> > I'm also unclear as to what you are checking - you seem to be putting
> > this in authlogin, but I had expected this to be a check between two
> > user contexts, identical in all respects except for the MLS ranges (one
> > from seusers, one from the user-supplied input).
> 
>  AIUI the code in authlogin allows all of the login type programs (like
> getty) to call the check. The check being performed is in policy/mls and
> is just:
> 
> mlsconstrain context transition
>        ( h1 dom h2 );
> 
> ...have I misunderstood this?

As I understood it (and the code in pam seems to match this), you were
going to generate two security contexts for the user session, one based
on seusers and one based on the provided range, otherwise identical in
all respects, and apply a permission check between those two contexts.
So for example, if my seusers-defined default context would be
staff_u:staff_r:staff_t:s0-s0:c0.c255 and I entered a level of s0:c3 as
input, there would be a permission check made by pam_selinux between
staff_u:staff_r:staff_t:s0-s0:c0.c255 and staff_u:staff_r:staff_t:s0:c3.
Thus, the TE rule would have to be between staff_t and itself (i.e. the
user domains), not between local_login_t and anything.

We aren't checking whether login can do anything (or using its context
anywhere); we are checking whether the seusers-defined default context
for the user contains the user-supplied context.

-- 
Stephen Smalley
National Security Agency


--
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: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Tue, 2006-10-31 at 10:11 -0500, Stephen Smalley wrote:

> As I understood it (and the code in pam seems to match this), you were
> going to generate two security contexts for the user session, one based
> on seusers and one based on the provided range, otherwise identical in
> all respects, and apply a permission check between those two contexts.
> So for example, if my seusers-defined default context would be
> staff_u:staff_r:staff_t:s0-s0:c0.c255 and I entered a level of s0:c3 as
> input, there would be a permission check made by pam_selinux between
> staff_u:staff_r:staff_t:s0-s0:c0.c255 and staff_u:staff_r:staff_t:s0:c3.

 This should all be true.

> Thus, the TE rule would have to be between staff_t and itself (i.e. the
> user domains), not between local_login_t and anything.

 Right. Does the mlsconstrain line not do that?

> We aren't checking whether login can do anything (or using its context
> anywhere); we are checking whether the seusers-defined default context
> for the user contains the user-supplied context.

 Right my understanding was that the policy line:

allow $1 domain:context transition

...meant that the login program could make security call:

 security_compute_av(src, dst, SECCLASS_CONTEXT, CONTEXT__TRANSITION, &avd)

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Tue, 2006-10-31 at 11:04 -0500, James Antill wrote:
> On Tue, 2006-10-31 at 10:11 -0500, Stephen Smalley wrote:
> 
> > As I understood it (and the code in pam seems to match this), you were
> > going to generate two security contexts for the user session, one based
> > on seusers and one based on the provided range, otherwise identical in
> > all respects, and apply a permission check between those two contexts.
> > So for example, if my seusers-defined default context would be
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and I entered a level of s0:c3 as
> > input, there would be a permission check made by pam_selinux between
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and staff_u:staff_r:staff_t:s0:c3.
> 
>  This should all be true.
> 
> > Thus, the TE rule would have to be between staff_t and itself (i.e. the
> > user domains), not between local_login_t and anything.
> 
>  Right. Does the mlsconstrain line not do that?

The mlsconstrain line wasn't my concern - it was the TE rule.

> > We aren't checking whether login can do anything (or using its context
> > anywhere); we are checking whether the seusers-defined default context
> > for the user contains the user-supplied context.
> 
>  Right my understanding was that the policy line:
> 
> allow $1 domain:context transition
> 
> ...meant that the login program could make security call:
> 
>  security_compute_av(src, dst, SECCLASS_CONTEXT, CONTEXT__TRANSITION, &avd)

No.  The ability to make the security call is controlled by the
compute_av permission on the security class, and isn't based on the
individual contexts passed as arguments.  That would be:
	allow $1 security_t:security compute_av;
which has an interface:
	selinux_compute_access_vector($1)
which is already in authlogin.if.  No change required for allowing the
call to happen.

What you are instead trying to do is to define the _result_ of that
compute_av call based on its arguments, not whether it can be made by
login.  So the TE rule would go into userdomain.if and be of the form:
	allow $1 self:context <permissionname>;

The mlsconstrain statement is ok, as long as it is sufficient to check
the high levels and not impose any constraint on the low levels.
 
-- 
Stephen Smalley
National Security Agency


--
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: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 1084 bytes --]

On Tue, 2006-10-31 at 11:21 -0500, Stephen Smalley wrote:

> No.  The ability to make the security call is controlled by the
> compute_av permission on the security class, and isn't based on the
> individual contexts passed as arguments.  That would be:
> 	allow $1 security_t:security compute_av;
> which has an interface:
> 	selinux_compute_access_vector($1)
> which is already in authlogin.if.  No change required for allowing the
> call to happen.
> 
> What you are instead trying to do is to define the _result_ of that
> compute_av call based on its arguments, not whether it can be made by
> login.  So the TE rule would go into userdomain.if and be of the form:
> 	allow $1 self:context <permissionname>;

 Ok, I think I have it now. Both patches are at (with the renamed
permission):

 http://people.redhat.com/jantill/pam-config_role/upstream/


-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #1.2: policy-pam-range-checking.patch --]
[-- Type: text/x-patch, Size: 1095 bytes --]

Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2065)
+++ policy/flask/access_vectors	(working copy)
@@ -635,4 +635,5 @@
 class context
 {
 	translate
+	contains
 }
Index: policy/modules/system/userdomain.if
===================================================================
--- policy/modules/system/userdomain.if	(revision 2065)
+++ policy/modules/system/userdomain.if	(working copy)
@@ -51,6 +51,8 @@
 	allow $1_t self:msg { send receive };
 	dontaudit $1_t self:socket create;
 
+	allow $1_t self:context contains;
+
 	allow $1_t $1_devpts_t:chr_file { setattr ioctl read getattr lock write append };
 	term_create_pty($1_t,$1_devpts_t)
 
Index: policy/mls
===================================================================
--- policy/mls	(revision 2065)
+++ policy/mls	(working copy)
@@ -596,4 +596,7 @@
 mlsconstrain context translate
 	(( h1 dom h2 ) or ( t1 == mlstranslate ));
 
+mlsconstrain context contains
+	( h1 dom h2 );
+
 ') dnl end enable_mls

[-- Attachment #1.3: selinux-pam-range-checking.patch --]
[-- Type: text/x-patch, Size: 987 bytes --]

Index: libselinux/include/selinux/av_permissions.h
===================================================================
--- libselinux/include/selinux/av_permissions.h	(revision 2074)
+++ libselinux/include/selinux/av_permissions.h	(working copy)
@@ -896,3 +896,4 @@
 #define KEY__SETATTR                              0x00000020UL
 #define KEY__CREATE                               0x00000040UL
 #define CONTEXT__TRANSLATE                        0x00000001UL
+#define CONTEXT__CONTAINS                         0x00000002UL
Index: libselinux/src/av_perm_to_string.h
===================================================================
--- libselinux/src/av_perm_to_string.h	(revision 2074)
+++ libselinux/src/av_perm_to_string.h	(working copy)
@@ -266,3 +266,4 @@
     S_(SECCLASS_KEY, KEY__SETATTR, "setattr")
     S_(SECCLASS_KEY, KEY__CREATE, "create")
     S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
+    S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Tue, 2006-10-31 at 13:33 -0500, James Antill wrote:
> On Tue, 2006-10-31 at 11:21 -0500, Stephen Smalley wrote:
> 
> > No.  The ability to make the security call is controlled by the
> > compute_av permission on the security class, and isn't based on the
> > individual contexts passed as arguments.  That would be:
> > 	allow $1 security_t:security compute_av;
> > which has an interface:
> > 	selinux_compute_access_vector($1)
> > which is already in authlogin.if.  No change required for allowing the
> > call to happen.
> > 
> > What you are instead trying to do is to define the _result_ of that
> > compute_av call based on its arguments, not whether it can be made by
> > login.  So the TE rule would go into userdomain.if and be of the form:
> > 	allow $1 self:context <permissionname>;
> 
>  Ok, I think I have it now. Both patches are at (with the renamed
> permission):
> 
>  http://people.redhat.com/jantill/pam-config_role/upstream/

They look sane to me.  Please post them in separate messages, preferably
inline, and cc Chris PeBenito on the policy patch.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

We still have a problem on MLS machines, in that newrole can be used to 
pass data via pseudo terminals.

script
newrole -l SystemHigh
cat TopSecret.doc
^d
^d
cat typescript

I propose we add this patch to newrole to check if we are on a pseudo 
terminal and then fail if user is using -l.

Basically this patch checks the major number of the stdin, stdout, 
stderr for a number in the pseudo number range,  If yes the pseudo 
terminal, if not continue.  Not pretty but it solves the problem.  I 
could not figure out another way to check if you are on a pseudo terminal. 

Comments?


diff --exclude-from=exclude --exclude POTFILES.in --exclude='*.po' 
--exclude='*.pot' -N -u -r nsapolicycoreutils/newrole/newrole.c 
policycoreutils-1.33.7/newrole/newrole.c
--- nsapolicycoreutils/newrole/newrole.c        2006-11-29 
17:11:18.000000000 -0500
+++ policycoreutils-1.33.7/newrole/newrole.c    2007-01-04 
16:24:47.000000000 -0500
@@ -67,6 +67,7 @@
 #include <selinux/get_context_list.h>  /* for SELINUX_DEFAULTUSER */
 #include <signal.h>
 #include <unistd.h>            /* for getuid(), exit(), getopt() */
+#include <sys/stat.h>
 #ifdef USE_AUDIT
 #include <libaudit.h>
 #endif
@@ -93,6 +94,19 @@

 extern char **environ;

+static int check_isapty(int fd) {
+       struct stat buf;
+       if ((isatty(fd)) && (fstat(fd, &buf) == 0)) {
+               int dev=major(buf.st_rdev);
+               if (dev >  135 && dev < 144) {
+                       return 1;
+               } else {
+                       return 0;
+               }
+       }
+       return 0;
+}
+                                      
 /**
  * Construct from the current range and specified desired level a resulting
  * range. If the specified level is a range, return that. If it is not, 
then
@@ -733,6 +747,7 @@
                                        security_context_t *new_context,
                                        int *preserve_environment)
 {
+       int i;                  /* index for open file descriptors */
        int flag_index;         /* flag index in argv[] */
        int clflag;             /* holds codes for command line flags */
        char *role_s = NULL;    /* role spec'd by user in argv[] */
@@ -793,6 +808,13 @@
                                        "specified\n"));
                                return -1;
                        }
+                       for (i=0; i < 3; i++) {
+                               if (check_isapty(i)) {
+                                       fprintf(stderr, "Error: you are 
not allowed to change levels on pseudo terminals\n");
+                                       return -1;
+                               }
+                       }
+
                        level_s = optarg;
                        break;
                default:


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Linda Knippers]

Daniel J Walsh wrote:
> We still have a problem on MLS machines, in that newrole can be used to
> pass data via pseudo terminals.
> 
> script
> newrole -l SystemHigh
> cat TopSecret.doc
> ^d
> ^d
> cat typescript
> 
> I propose we add this patch to newrole to check if we are on a pseudo
> terminal and then fail if user is using -l.
> 
> Basically this patch checks the major number of the stdin, stdout,
> stderr for a number in the pseudo number range,  If yes the pseudo
> terminal, if not continue.  Not pretty but it solves the problem.  I
> could not figure out another way to check if you are on a pseudo terminal.
> Comments?
> 
> 
> diff --exclude-from=exclude --exclude POTFILES.in --exclude='*.po'
> --exclude='*.pot' -N -u -r nsapolicycoreutils/newrole/newrole.c
> policycoreutils-1.33.7/newrole/newrole.c
> --- nsapolicycoreutils/newrole/newrole.c        2006-11-29
> 17:11:18.000000000 -0500
> +++ policycoreutils-1.33.7/newrole/newrole.c    2007-01-04
> 16:24:47.000000000 -0500
> @@ -67,6 +67,7 @@
> #include <selinux/get_context_list.h>  /* for SELINUX_DEFAULTUSER */
> #include <signal.h>
> #include <unistd.h>            /* for getuid(), exit(), getopt() */
> +#include <sys/stat.h>
> #ifdef USE_AUDIT
> #include <libaudit.h>
> #endif
> @@ -93,6 +94,19 @@
> 
> extern char **environ;
> 
> +static int check_isapty(int fd) {
> +       struct stat buf;
> +       if ((isatty(fd)) && (fstat(fd, &buf) == 0)) {
> +               int dev=major(buf.st_rdev);
> +               if (dev >  135 && dev < 144) {

Where do these numbers come from?  Is UNIX98_PTY_SLAVE_MAJOR in
/usr/include/linux/major.h useful?  That's what the value is on
my system.  There's also PTY_SLAVE_MAJOR (value of 3) in that
file, but on my system that's the major for real ttys.

> +                       return 1;
> +               } else {
> +                       return 0;
> +               }
> +       }
> +       return 0;
> +}
> +                                      /**
>  * Construct from the current range and specified desired level a resulting
>  * range. If the specified level is a range, return that. If it is not,
> then
> @@ -733,6 +747,7 @@
>                                        security_context_t *new_context,
>                                        int *preserve_environment)
> {
> +       int i;                  /* index for open file descriptors */
>        int flag_index;         /* flag index in argv[] */
>        int clflag;             /* holds codes for command line flags */
>        char *role_s = NULL;    /* role spec'd by user in argv[] */
> @@ -793,6 +808,13 @@
>                                        "specified\n"));
>                                return -1;
>                        }
> +                       for (i=0; i < 3; i++) {
> +                               if (check_isapty(i)) {
> +                                       fprintf(stderr, "Error: you are
> not allowed to change levels on pseudo terminals\n");
> +                                       return -1;
> +                               }
> +                       }
> +
>                        level_s = optarg;
>                        break;
>                default:
> 
> 
> -- 
> 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.


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

Linda Knippers wrote:
> Daniel J Walsh wrote:
>   
>> We still have a problem on MLS machines, in that newrole can be used to
>> pass data via pseudo terminals.
>>
>> script
>> newrole -l SystemHigh
>> cat TopSecret.doc
>> ^d
>> ^d
>> cat typescript
>>
>> I propose we add this patch to newrole to check if we are on a pseudo
>> terminal and then fail if user is using -l.
>>
>> Basically this patch checks the major number of the stdin, stdout,
>> stderr for a number in the pseudo number range,  If yes the pseudo
>> terminal, if not continue.  Not pretty but it solves the problem.  I
>> could not figure out another way to check if you are on a pseudo terminal.
>> Comments?
>>
>>
>> diff --exclude-from=exclude --exclude POTFILES.in --exclude='*.po'
>> --exclude='*.pot' -N -u -r nsapolicycoreutils/newrole/newrole.c
>> policycoreutils-1.33.7/newrole/newrole.c
>> --- nsapolicycoreutils/newrole/newrole.c        2006-11-29
>> 17:11:18.000000000 -0500
>> +++ policycoreutils-1.33.7/newrole/newrole.c    2007-01-04
>> 16:24:47.000000000 -0500
>> @@ -67,6 +67,7 @@
>> #include <selinux/get_context_list.h>  /* for SELINUX_DEFAULTUSER */
>> #include <signal.h>
>> #include <unistd.h>            /* for getuid(), exit(), getopt() */
>> +#include <sys/stat.h>
>> #ifdef USE_AUDIT
>> #include <libaudit.h>
>> #endif
>> @@ -93,6 +94,19 @@
>>
>> extern char **environ;
>>
>> +static int check_isapty(int fd) {
>> +       struct stat buf;
>> +       if ((isatty(fd)) && (fstat(fd, &buf) == 0)) {
>> +               int dev=major(buf.st_rdev);
>> +               if (dev >  135 && dev < 144) {
>>     
>
> Where do these numbers come from?  Is UNIX98_PTY_SLAVE_MAJOR in
> /usr/include/linux/major.h useful?  That's what the value is on
> my system.  There's also PTY_SLAVE_MAJOR (value of 3) in that
> file, but on my system that's the major for real ttys.
>
>   
>> +                       return 1;
>> +               } else {
>> +                       return 0;
>> +               }
>> +       }
>> +       return 0;
>> +}
>> +                                      /**
>>  * Construct from the current range and specified desired level a resulting
>>  * range. If the specified level is a range, return that. If it is not,
>> then
>> @@ -733,6 +747,7 @@
>>                                        security_context_t *new_context,
>>                                        int *preserve_environment)
>> {
>> +       int i;                  /* index for open file descriptors */
>>        int flag_index;         /* flag index in argv[] */
>>        int clflag;             /* holds codes for command line flags */
>>        char *role_s = NULL;    /* role spec'd by user in argv[] */
>> @@ -793,6 +808,13 @@
>>                                        "specified\n"));
>>                                return -1;
>>                        }
>> +                       for (i=0; i < 3; i++) {
>> +                               if (check_isapty(i)) {
>> +                                       fprintf(stderr, "Error: you are
>> not allowed to change levels on pseudo terminals\n");
>> +                                       return -1;
>> +                               }
>> +                       }
>> +
>>                        level_s = optarg;
>>                        break;
>>                default:
>>
>>
>> -- 
>> 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.
>>     
devices.txt in kernel documentation.

> 2176 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2176>	136-143 char	Unix98 PTY slaves
> 2177 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2177>			  0 = /dev/pts/0	First Unix98 pseudo-TTY
> 2178 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2178>			  1 = /dev/pts/1	Second Unix98 pesudo-TTY
> 2179 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2179>			    ...
> 2180 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2180>	
> 2181 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2181>			These device nodes are automatically generated with
> 2182 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2182>			the proper permissions and modes by mounting the
> 2183 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2183>			devpts filesystem onto /dev/pts with the appropriate
> 2184 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2184>			mount options (distribution dependent, however, on
> 2185 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2185>			*most* distributions the appropriate options are
> 2186 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2186>			"mode=0620,gid=<gid of the "tty" group>".)
> 2187 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2187>	


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Linda Knippers]

> devices.txt in kernel documentation. 
> 2176 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2176>    136-143 char    Unix98 PTY slaves 

Since that document has multiple devices with the same major, I wonder if its
safer to fstatfs() the fd and make sure the f_type is the devpts fs magic
number.  It only seems to be defined in fs/devpts/inode.c though.

> #define DEVPTS_SUPER_MAGIC 0x1cd1

devpts is mounted on /dev/pts before single user mode so it seems to always
be there unless someone unmounts it.  If you try to ssh in without /dev/pts
mounted the ssh hangs.

-- ljk

--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

On Thu, Jan 04, 2007 at 06:19:13PM -0500, Linda Knippers wrote:
> > devices.txt in kernel documentation. 
> > 2176 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2176>    136-143 char    Unix98 PTY slaves 
> 
> Since that document has multiple devices with the same major, I wonder if its
> safer to fstatfs() the fd and make sure the f_type is the devpts fs magic
> number.  It only seems to be defined in fs/devpts/inode.c though.
> 
> > #define DEVPTS_SUPER_MAGIC 0x1cd1
> 
> devpts is mounted on /dev/pts before single user mode so it seems to always
> be there unless someone unmounts it.  If you try to ssh in without /dev/pts
> mounted the ssh hangs.

I think blacklists are usually a bad idea for security, for example this
breaks if people have a kernel that supports the old-style ptys that
don't use devpts. How about turning it around and only allowing use of
known good ttys, similar to /etc/securetty, or insisting on type
"tty_device_t" which includes the virtual console and serial terminals
but not the ptys?

-Klaus

--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Joshua Brindle]

Klaus Weidner wrote:
> On Thu, Jan 04, 2007 at 06:19:13PM -0500, Linda Knippers wrote:
>   
>>> devices.txt in kernel documentation. 
>>> 2176 <http://www.mjmwired.net/kernel/Documentation/devices.txt#2176>    136-143 char    Unix98 PTY slaves 
>>>       
>> Since that document has multiple devices with the same major, I wonder if its
>> safer to fstatfs() the fd and make sure the f_type is the devpts fs magic
>> number.  It only seems to be defined in fs/devpts/inode.c though.
>>
>>     
>>> #define DEVPTS_SUPER_MAGIC 0x1cd1
>>>       
>> devpts is mounted on /dev/pts before single user mode so it seems to always
>> be there unless someone unmounts it.  If you try to ssh in without /dev/pts
>> mounted the ssh hangs.
>>     
>
> I think blacklists are usually a bad idea for security, for example this
> breaks if people have a kernel that supports the old-style ptys that
> don't use devpts. How about turning it around and only allowing use of
> known good ttys, similar to /etc/securetty, or insisting on type
> "tty_device_t" which includes the virtual console and serial terminals
> but not the ptys?
>   
Hardcoding types into code makes it inflexible to policy changes, this 
is a bad idea IMO, the tty whitelist, however, is probably the way to 
go. I don't know if we should use the existing /etc/securetty or  add 
our own file though.


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

On Thu, Jan 04, 2007 at 10:05:57PM -0500, Joshua Brindle wrote:
> Hardcoding types into code makes it inflexible to policy changes, this 
> is a bad idea IMO, the tty whitelist, however, is probably the way to 
> go. I don't know if we should use the existing /etc/securetty or  add 
> our own file though.

I'm not sure if the existing /etc/securetty is the right one, since
people may make serial terminals available to users but would not want
direct root login on those. Well, maybe not terribly likely these days.

Instead of hardcoded types, how about a configurable type or a
/etc/securettytypes file that contains the types instead of tty names?

-Klaus

--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Joshua Brindle]

> From: Klaus Weidner [mailto:klaus@atsec.com] 
> 
> On Thu, Jan 04, 2007 at 10:05:57PM -0500, Joshua Brindle wrote:
> > Hardcoding types into code makes it inflexible to policy 
> changes, this 
> > is a bad idea IMO, the tty whitelist, however, is probably 
> the way to 
> > go. I don't know if we should use the existing 
> /etc/securetty or  add 
> > our own file though.
> 
> I'm not sure if the existing /etc/securetty is the right one, 
> since people may make serial terminals available to users but 
> would not want direct root login on those. Well, maybe not 
> terribly likely these days.
> 
> Instead of hardcoded types, how about a configurable type or 
> a /etc/securettytypes file that contains the types instead of 
> tty names?

Sure, the securettycontexts might be the way to go. I'm dubious about
just making this happen for level changes though, you shouldn't be able
to bypass any part of the security policy using newrole.


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

On Thu, Jan 04, 2007 at 10:35:45PM -0500, Joshua Brindle wrote:
> > From: Klaus Weidner [mailto:klaus@atsec.com] 
> > Instead of hardcoded types, how about a configurable type or 
> > a /etc/securettytypes file that contains the types instead of 
> > tty names?
> 
> Sure, the securettycontexts might be the way to go. I'm dubious about
> just making this happen for level changes though, you shouldn't be able
> to bypass any part of the security policy using newrole.

The problem isn't actually in newrole, so this is a workaround to
close an information leak in MLS environments without causing problems
for everyone else who wouldn't care about this leak. Newrole has special
privileges (specifically the "mlsprocsetsl" attribute) which make it a
trusted program, and I think it's reasonable to have a trusted program
enforce part of the security policy.

>From what I recall from the previous discussions, there is a lot of
resistance to implementing SELinux hooks in the PTY layer which would be
needed to enforce the restriction at the kernel level.

A permission check at the PTY level would most likely require a fair
amount of policy to avoid TE denials, and even getting just the MLS
constraints to work would be tricky. For example, which of the processes
involved at the ends of the PTY should gain MLS override privileges due
to its type attributes if any?

-Klaus

--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2007-01-04 at 22:01 -0600, Klaus Weidner wrote:
> On Thu, Jan 04, 2007 at 10:35:45PM -0500, Joshua Brindle wrote:
> > > From: Klaus Weidner [mailto:klaus@atsec.com] 
> > > Instead of hardcoded types, how about a configurable type or 
> > > a /etc/securettytypes file that contains the types instead of 
> > > tty names?
> > 
> > Sure, the securettycontexts might be the way to go. I'm dubious about
> > just making this happen for level changes though, you shouldn't be able
> > to bypass any part of the security policy using newrole.
> 
> The problem isn't actually in newrole, so this is a workaround to
> close an information leak in MLS environments without causing problems
> for everyone else who wouldn't care about this leak. Newrole has special
> privileges (specifically the "mlsprocsetsl" attribute) which make it a
> trusted program, and I think it's reasonable to have a trusted program
> enforce part of the security policy.
> 
> >From what I recall from the previous discussions, there is a lot of
> resistance to implementing SELinux hooks in the PTY layer which would be
> needed to enforce the restriction at the kernel level.

Not so much resistance as uncertainty as to what form such a check would
take and how effective it would be.

> A permission check at the PTY level would most likely require a fair
> amount of policy to avoid TE denials, and even getting just the MLS
> constraints to work would be tricky. For example, which of the processes
> involved at the ends of the PTY should gain MLS override privileges due
> to its type attributes if any?
> 
> -Klaus
-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 35 bytes --]

libselinux securetty_context patch

[-- Attachment #2: libselinux-rhat.patch --]
[-- Type: text/x-patch, Size: 19123 bytes --]

diff --exclude-from=exclude -N -u -r nsalibselinux/debugfiles.list libselinux-1.33.3/debugfiles.list
--- nsalibselinux/debugfiles.list	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/debugfiles.list	2007-01-05 10:24:49.000000000 -0500
@@ -0,0 +1,10 @@
+/usr/lib/debug/usr/sbin/getsebool.debug
+/usr/lib/debug/usr/sbin/getenforce.debug
+/usr/lib/debug/usr/sbin/selinuxenabled.debug
+/usr/lib/debug/usr/sbin/avcstat.debug
+/usr/lib/debug/usr/sbin/matchpathcon.debug
+/usr/lib/debug/usr/sbin/togglesebool.debug
+/usr/lib/debug/usr/sbin/setenforce.debug
+/usr/lib/debug/usr/lib/python2.4/site-packages/_selinux.so.debug
+/usr/lib/debug/lib/libselinux.so.1.debug
+/usr/src/debug/libselinux-1.33.3
Binary files nsalibselinux/debugsources.list and libselinux-1.33.3/debugsources.list differ
diff --exclude-from=exclude -N -u -r nsalibselinux/include/selinux/selinux.h libselinux-1.33.3/include/selinux/selinux.h
--- nsalibselinux/include/selinux/selinux.h	2006-11-16 17:15:18.000000000 -0500
+++ libselinux-1.33.3/include/selinux/selinux.h	2007-01-05 10:24:22.000000000 -0500
@@ -406,6 +406,7 @@
 	extern const char *selinux_homedir_context_path(void);
 	extern const char *selinux_media_context_path(void);
 	extern const char *selinux_contexts_path(void);
+	extern const char *selinux_securetty_context_path(void);
 	extern const char *selinux_booleans_path(void);
 	extern const char *selinux_customizable_types_path(void);
 	extern const char *selinux_users_path(void);
@@ -413,12 +414,14 @@
 	extern const char *selinux_translations_path(void);
 	extern const char *selinux_netfilter_context_path(void);
 	extern const char *selinux_path(void);
-
 /* Check a permission in the passwd class.
    Return 0 if granted or -1 otherwise. */
 	extern int selinux_check_passwd_access(access_vector_t requested);
 	extern int checkPasswdAccess(access_vector_t requested);
 
+/* Check if the tty_context is defined as a securetty
+   Return 1 if secure, 0 if not, or -1 if otherwise. */
+	extern int selinux_check_securetty_context(security_context_t tty_context);
 /* Set the path to the selinuxfs mount point explicitly.
    Normally, this is determined automatically during libselinux 
    initialization, but this is not always possible, e.g. for /sbin/init
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_binary_policy_path.3 libselinux-1.33.3/man/man3/selinux_binary_policy_path.3
--- nsalibselinux/man/man3/selinux_binary_policy_path.3	2006-11-16 17:15:30.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_binary_policy_path.3	2007-01-05 10:24:22.000000000 -0500
@@ -27,6 +27,8 @@
 .br
 extern const char *selinux_media_context_path(void);
 .br
+extern const char *selinux_securetty_context_path(void);
+.br
 extern const char *selinux_contexts_path(void);
 .br
 extern const char *selinux_booleans_path(void);
@@ -56,6 +58,8 @@
 .sp
 selinux_contexts_path() - directory containing all of the context configuration files
 .sp
+selinux_securetty_context_path() - defines terminal contexts for securetty
+.sp
 selinux_booleans_path() - initial policy boolean settings
 
 .SH AUTHOR	
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_check_securetty_context.3 libselinux-1.33.3/man/man3/selinux_check_securetty_context.3
--- nsalibselinux/man/man3/selinux_check_securetty_context.3	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_check_securetty_context.3	2007-01-05 10:24:22.000000000 -0500
@@ -0,0 +1,13 @@
+.TH "selinux_check_securetty_context" "3" "1 January 2007" "dwalsh@redhat.com" "SE Linux API documentation"
+.SH "NAME"
+selinux_check_securetty_context \- check whether a tty security context is defined as a securetty context
+.SH "SYNOPSIS"
+.B #include <selinux/selinux.h>
+.sp
+.BI "int selinux_check_securetty_context(security_context_t "tty_context );
+
+.SH "DESCRIPTION"
+.B selinux_check_securetty_context
+returns 1 if tty_context is a securetty context
+returns 0 if tty_context is a not a securetty context
+returns -1 on error.
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_securetty_context_path.3 libselinux-1.33.3/man/man3/selinux_securetty_context_path.3
--- nsalibselinux/man/man3/selinux_securetty_context_path.3	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_securetty_context_path.3	2007-01-05 10:24:22.000000000 -0500
@@ -0,0 +1 @@
+.so man3/selinux_binary_policy_path.3
Binary files nsalibselinux/src/avc_internal.lo and libselinux-1.33.3/src/avc_internal.lo differ
Binary files nsalibselinux/src/avc_internal.o and libselinux-1.33.3/src/avc_internal.o differ
Binary files nsalibselinux/src/avc.lo and libselinux-1.33.3/src/avc.lo differ
Binary files nsalibselinux/src/avc.o and libselinux-1.33.3/src/avc.o differ
Binary files nsalibselinux/src/avc_sidtab.lo and libselinux-1.33.3/src/avc_sidtab.lo differ
Binary files nsalibselinux/src/avc_sidtab.o and libselinux-1.33.3/src/avc_sidtab.o differ
Binary files nsalibselinux/src/booleans.lo and libselinux-1.33.3/src/booleans.lo differ
Binary files nsalibselinux/src/booleans.o and libselinux-1.33.3/src/booleans.o differ
Binary files nsalibselinux/src/canonicalize_context.lo and libselinux-1.33.3/src/canonicalize_context.lo differ
Binary files nsalibselinux/src/canonicalize_context.o and libselinux-1.33.3/src/canonicalize_context.o differ
Binary files nsalibselinux/src/checkAccess.lo and libselinux-1.33.3/src/checkAccess.lo differ
Binary files nsalibselinux/src/checkAccess.o and libselinux-1.33.3/src/checkAccess.o differ
Binary files nsalibselinux/src/check_context.lo and libselinux-1.33.3/src/check_context.lo differ
Binary files nsalibselinux/src/check_context.o and libselinux-1.33.3/src/check_context.o differ
Binary files nsalibselinux/src/compute_av.lo and libselinux-1.33.3/src/compute_av.lo differ
Binary files nsalibselinux/src/compute_av.o and libselinux-1.33.3/src/compute_av.o differ
Binary files nsalibselinux/src/compute_create.lo and libselinux-1.33.3/src/compute_create.lo differ
Binary files nsalibselinux/src/compute_create.o and libselinux-1.33.3/src/compute_create.o differ
Binary files nsalibselinux/src/compute_member.lo and libselinux-1.33.3/src/compute_member.lo differ
Binary files nsalibselinux/src/compute_member.o and libselinux-1.33.3/src/compute_member.o differ
Binary files nsalibselinux/src/compute_relabel.lo and libselinux-1.33.3/src/compute_relabel.lo differ
Binary files nsalibselinux/src/compute_relabel.o and libselinux-1.33.3/src/compute_relabel.o differ
Binary files nsalibselinux/src/compute_user.lo and libselinux-1.33.3/src/compute_user.lo differ
Binary files nsalibselinux/src/compute_user.o and libselinux-1.33.3/src/compute_user.o differ
Binary files nsalibselinux/src/context.lo and libselinux-1.33.3/src/context.lo differ
Binary files nsalibselinux/src/context.o and libselinux-1.33.3/src/context.o differ
Binary files nsalibselinux/src/disable.lo and libselinux-1.33.3/src/disable.lo differ
Binary files nsalibselinux/src/disable.o and libselinux-1.33.3/src/disable.o differ
Binary files nsalibselinux/src/enabled.lo and libselinux-1.33.3/src/enabled.lo differ
Binary files nsalibselinux/src/enabled.o and libselinux-1.33.3/src/enabled.o differ
Binary files nsalibselinux/src/fgetfilecon.lo and libselinux-1.33.3/src/fgetfilecon.lo differ
Binary files nsalibselinux/src/fgetfilecon.o and libselinux-1.33.3/src/fgetfilecon.o differ
diff --exclude-from=exclude -N -u -r nsalibselinux/src/file_path_suffixes.h libselinux-1.33.3/src/file_path_suffixes.h
--- nsalibselinux/src/file_path_suffixes.h	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/file_path_suffixes.h	2007-01-05 10:24:22.000000000 -0500
@@ -7,6 +7,7 @@
     S_(USER_CONTEXTS, "/contexts/users/")
     S_(FAILSAFE_CONTEXT, "/contexts/failsafe_context")
     S_(DEFAULT_TYPE, "/contexts/default_type")
+    S_(SECURETTY_CONTEXTS, "/contexts/securetty_contexts")
     S_(BOOLEANS, "/booleans")
     S_(MEDIA_CONTEXTS, "/contexts/files/media")
     S_(REMOVABLE_CONTEXT, "/contexts/removable_context")
Binary files nsalibselinux/src/freeconary.lo and libselinux-1.33.3/src/freeconary.lo differ
Binary files nsalibselinux/src/freeconary.o and libselinux-1.33.3/src/freeconary.o differ
Binary files nsalibselinux/src/freecon.lo and libselinux-1.33.3/src/freecon.lo differ
Binary files nsalibselinux/src/freecon.o and libselinux-1.33.3/src/freecon.o differ
Binary files nsalibselinux/src/fsetfilecon.lo and libselinux-1.33.3/src/fsetfilecon.lo differ
Binary files nsalibselinux/src/fsetfilecon.o and libselinux-1.33.3/src/fsetfilecon.o differ
Binary files nsalibselinux/src/get_context_list.lo and libselinux-1.33.3/src/get_context_list.lo differ
Binary files nsalibselinux/src/get_context_list.o and libselinux-1.33.3/src/get_context_list.o differ
Binary files nsalibselinux/src/get_default_type.lo and libselinux-1.33.3/src/get_default_type.lo differ
Binary files nsalibselinux/src/get_default_type.o and libselinux-1.33.3/src/get_default_type.o differ
Binary files nsalibselinux/src/getenforce.lo and libselinux-1.33.3/src/getenforce.lo differ
Binary files nsalibselinux/src/getenforce.o and libselinux-1.33.3/src/getenforce.o differ
Binary files nsalibselinux/src/getfilecon.lo and libselinux-1.33.3/src/getfilecon.lo differ
Binary files nsalibselinux/src/getfilecon.o and libselinux-1.33.3/src/getfilecon.o differ
Binary files nsalibselinux/src/getpeercon.lo and libselinux-1.33.3/src/getpeercon.lo differ
Binary files nsalibselinux/src/getpeercon.o and libselinux-1.33.3/src/getpeercon.o differ
Binary files nsalibselinux/src/init.lo and libselinux-1.33.3/src/init.lo differ
Binary files nsalibselinux/src/init.o and libselinux-1.33.3/src/init.o differ
Binary files nsalibselinux/src/is_customizable_type.lo and libselinux-1.33.3/src/is_customizable_type.lo differ
Binary files nsalibselinux/src/is_customizable_type.o and libselinux-1.33.3/src/is_customizable_type.o differ
Binary files nsalibselinux/src/lgetfilecon.lo and libselinux-1.33.3/src/lgetfilecon.lo differ
Binary files nsalibselinux/src/lgetfilecon.o and libselinux-1.33.3/src/lgetfilecon.o differ
Binary files nsalibselinux/src/libselinux.a and libselinux-1.33.3/src/libselinux.a differ
Binary files nsalibselinux/src/libselinux.so and libselinux-1.33.3/src/libselinux.so differ
Binary files nsalibselinux/src/libselinux.so.1 and libselinux-1.33.3/src/libselinux.so.1 differ
Binary files nsalibselinux/src/load_policy.lo and libselinux-1.33.3/src/load_policy.lo differ
Binary files nsalibselinux/src/load_policy.o and libselinux-1.33.3/src/load_policy.o differ
Binary files nsalibselinux/src/lsetfilecon.lo and libselinux-1.33.3/src/lsetfilecon.lo differ
Binary files nsalibselinux/src/lsetfilecon.o and libselinux-1.33.3/src/lsetfilecon.o differ
Binary files nsalibselinux/src/matchmediacon.lo and libselinux-1.33.3/src/matchmediacon.lo differ
Binary files nsalibselinux/src/matchmediacon.o and libselinux-1.33.3/src/matchmediacon.o differ
Binary files nsalibselinux/src/matchpathcon.lo and libselinux-1.33.3/src/matchpathcon.lo differ
Binary files nsalibselinux/src/matchpathcon.o and libselinux-1.33.3/src/matchpathcon.o differ
Binary files nsalibselinux/src/policyvers.lo and libselinux-1.33.3/src/policyvers.lo differ
Binary files nsalibselinux/src/policyvers.o and libselinux-1.33.3/src/policyvers.o differ
Binary files nsalibselinux/src/procattr.lo and libselinux-1.33.3/src/procattr.lo differ
Binary files nsalibselinux/src/procattr.o and libselinux-1.33.3/src/procattr.o differ
Binary files nsalibselinux/src/query_user_context.lo and libselinux-1.33.3/src/query_user_context.lo differ
Binary files nsalibselinux/src/query_user_context.o and libselinux-1.33.3/src/query_user_context.o differ
Binary files nsalibselinux/src/rpm.lo and libselinux-1.33.3/src/rpm.lo differ
Binary files nsalibselinux/src/rpm.o and libselinux-1.33.3/src/rpm.o differ
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_check_securetty_context.c libselinux-1.33.3/src/selinux_check_securetty_context.c
--- nsalibselinux/src/selinux_check_securetty_context.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/src/selinux_check_securetty_context.c	2007-01-05 10:33:18.000000000 -0500
@@ -0,0 +1,44 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <ctype.h>
+#include "selinux_internal.h"
+#include "context_internal.h"
+
+int selinux_check_securetty_context(security_context_t tty_context)
+{
+	char buf[250];
+	char *ptr = "", *end;
+	size_t len;
+	int found = -1;
+	FILE *fp;
+
+	fp = fopen(selinux_securetty_context_path(), "r");
+	if (fp) {
+		found = 0;
+		len = strlen(tty_context);
+		while (!feof_unlocked(fp)) {
+			if (!fgets_unlocked(buf, sizeof buf, fp))
+				return found;
+			if (buf[strlen(buf) - 1])
+				buf[strlen(buf) - 1] = 0;
+
+			ptr = buf;
+			while (*ptr && isspace(*ptr))
+				ptr++;
+			if (!(*ptr))
+				continue;
+
+			if (!strncmp(tty_context, ptr, len)) {
+				found = 1;
+				break;
+			}
+		}
+		fclose(fp);
+	}
+
+	return found;
+}
+
+hidden_def(selinux_check_securetty_context)
Binary files nsalibselinux/src/selinux_check_securetty_context.lo and libselinux-1.33.3/src/selinux_check_securetty_context.lo differ
Binary files nsalibselinux/src/selinux_check_securetty_context.o and libselinux-1.33.3/src/selinux_check_securetty_context.o differ
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_config.c libselinux-1.33.3/src/selinux_config.c
--- nsalibselinux/src/selinux_config.c	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/selinux_config.c	2007-01-05 10:24:22.000000000 -0500
@@ -38,7 +38,8 @@
 #define NETFILTER_CONTEXTS    15
 #define FILE_CONTEXTS_HOMEDIR 16
 #define FILE_CONTEXTS_LOCAL 17
-#define NEL               18
+#define SECURETTY_CONTEXTS  18
+#define NEL               19
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -299,6 +300,12 @@
 
 hidden_def(selinux_default_context_path)
 
+const char *selinux_securetty_context_path()
+{
+	return get_path(SECURETTY_CONTEXTS);
+}
+hidden_def(selinux_securetty_context_path)
+
 const char *selinux_failsafe_context_path()
 {
 	return get_path(FAILSAFE_CONTEXT);
Binary files nsalibselinux/src/selinux_config.lo and libselinux-1.33.3/src/selinux_config.lo differ
Binary files nsalibselinux/src/selinux_config.o and libselinux-1.33.3/src/selinux_config.o differ
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_internal.h libselinux-1.33.3/src/selinux_internal.h
--- nsalibselinux/src/selinux_internal.h	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/selinux_internal.h	2007-01-05 10:24:22.000000000 -0500
@@ -53,6 +53,7 @@
     hidden_proto(security_setenforce)
     hidden_proto(selinux_binary_policy_path)
     hidden_proto(selinux_default_context_path)
+    hidden_proto(selinux_securetty_context_path)
     hidden_proto(selinux_failsafe_context_path)
     hidden_proto(selinux_removable_context_path)
     hidden_proto(selinux_file_context_path)
@@ -66,6 +67,7 @@
     hidden_proto(selinux_media_context_path)
     hidden_proto(selinux_path)
     hidden_proto(selinux_check_passwd_access)
+    hidden_proto(selinux_check_securetty_context)
     hidden_proto(matchpathcon_init_prefix)
     hidden_proto(selinux_users_path)
     hidden_proto(selinux_usersconf_path);
Binary files nsalibselinux/src/_selinux.so and libselinux-1.33.3/src/_selinux.so differ
Binary files nsalibselinux/src/selinuxswig_wrap.lo and libselinux-1.33.3/src/selinuxswig_wrap.lo differ
Binary files nsalibselinux/src/setenforce.lo and libselinux-1.33.3/src/setenforce.lo differ
Binary files nsalibselinux/src/setenforce.o and libselinux-1.33.3/src/setenforce.o differ
Binary files nsalibselinux/src/setfilecon.lo and libselinux-1.33.3/src/setfilecon.lo differ
Binary files nsalibselinux/src/setfilecon.o and libselinux-1.33.3/src/setfilecon.o differ
Binary files nsalibselinux/src/setrans_client.lo and libselinux-1.33.3/src/setrans_client.lo differ
Binary files nsalibselinux/src/setrans_client.o and libselinux-1.33.3/src/setrans_client.o differ
Binary files nsalibselinux/src/seusers.lo and libselinux-1.33.3/src/seusers.lo differ
Binary files nsalibselinux/src/seusers.o and libselinux-1.33.3/src/seusers.o differ
Binary files nsalibselinux/utils/avcstat and libselinux-1.33.3/utils/avcstat differ
Binary files nsalibselinux/utils/compute_av and libselinux-1.33.3/utils/compute_av differ
Binary files nsalibselinux/utils/compute_create and libselinux-1.33.3/utils/compute_create differ
Binary files nsalibselinux/utils/compute_member and libselinux-1.33.3/utils/compute_member differ
Binary files nsalibselinux/utils/compute_relabel and libselinux-1.33.3/utils/compute_relabel differ
Binary files nsalibselinux/utils/compute_user and libselinux-1.33.3/utils/compute_user differ
Binary files nsalibselinux/utils/getconlist and libselinux-1.33.3/utils/getconlist differ
Binary files nsalibselinux/utils/getenforce and libselinux-1.33.3/utils/getenforce differ
Binary files nsalibselinux/utils/getfilecon and libselinux-1.33.3/utils/getfilecon differ
Binary files nsalibselinux/utils/getpidcon and libselinux-1.33.3/utils/getpidcon differ
Binary files nsalibselinux/utils/getsebool and libselinux-1.33.3/utils/getsebool differ
Binary files nsalibselinux/utils/getseuser and libselinux-1.33.3/utils/getseuser differ
Binary files nsalibselinux/utils/matchpathcon and libselinux-1.33.3/utils/matchpathcon differ
Binary files nsalibselinux/utils/policyvers and libselinux-1.33.3/utils/policyvers differ
Binary files nsalibselinux/utils/selinux_check_securetty_context and libselinux-1.33.3/utils/selinux_check_securetty_context differ
diff --exclude-from=exclude -N -u -r nsalibselinux/utils/selinux_check_securetty_context.c libselinux-1.33.3/utils/selinux_check_securetty_context.c
--- nsalibselinux/utils/selinux_check_securetty_context.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/utils/selinux_check_securetty_context.c	2007-01-05 10:26:51.000000000 -0500
@@ -0,0 +1,40 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <getopt.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/errno.h>
+#include <selinux/selinux.h>
+
+void usage(const char *progname)
+{
+	fprintf(stderr,
+		"usage:  %s tty_context...\n",
+		progname);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	int i;
+	if (argc < 2)
+		usage(argv[0]);
+
+	for (i = 1; i < argc; i++) {
+		switch (selinux_check_securetty_context(argv[i])) {
+		case 1:
+			printf("%s securetty.\n", argv[i]);
+			break;
+		case 0:
+			printf("%s not securetty.\n", argv[i]);
+			break;
+		case -1:
+			perror("Failed on check if securetty");
+			return -1;
+		}
+	}
+	return 0;
+}
Binary files nsalibselinux/utils/selinuxenabled and libselinux-1.33.3/utils/selinuxenabled differ
Binary files nsalibselinux/utils/setenforce and libselinux-1.33.3/utils/setenforce differ
Binary files nsalibselinux/utils/setfilecon and libselinux-1.33.3/utils/setfilecon differ
Binary files nsalibselinux/utils/togglesebool and libselinux-1.33.3/utils/togglesebool differ

Re: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

newrole patch. for checking securetty.


diff --exclude-from=exclude --exclude POTFILES.in --exclude='*.po' 
--exclude='*.pot' -N -u -r nsapolicycoreutils/newrole/newrole.c 
policycoreutils-1.33.8/newrole/newrole.c
--- nsapolicycoreutils/newrole/newrole.c        2007-01-04 
17:01:41.000000000 -0500
+++ policycoreutils-1.33.8/newrole/newrole.c    2007-01-05 
11:17:36.000000000 -0500
@@ -733,6 +734,7 @@
                                        security_context_t *new_context,
                                        int *preserve_environment)
 {
+       int i;                  /* index for open file descriptors */
        int flag_index;         /* flag index in argv[] */
        int clflag;             /* holds codes for command line flags */
        char *role_s = NULL;    /* role spec'd by user in argv[] */
@@ -741,6 +743,8 @@
        char *level_s = NULL;   /* level spec'd by user in argv[] */
        char *range_ptr = NULL;
        security_context_t new_con = NULL;
+       security_context_t tty_con = NULL;
+       int securetty=0;
        context_t context = NULL; /* manipulatable form of new_context */
        const struct option long_options[] = {
                {"role", 1, 0, 'r'},
@@ -793,6 +797,18 @@
                                        "specified\n"));
                                return -1;
                        }
+                       for (i=0; i < 3; i++) {
+                               securetty=0;
+                               if (fgetfilecon(i,&tty_con) >= 0) {
+                                       securetty = 
(selinux_check_securetty_context(tty_con) == 1);
+                                       freecon(tty_con);
+                               }
+                               if (!securetty) {
+                                       fprintf(stderr, "Error: you are 
not allowed to change levels on a non secure terminal\n");
+                                       return -1;
+                               }
+                       }
+
                        level_s = optarg;
                        break;
                default:


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

First libselinux-rhat patch was broken.  Needs to only check the context 
type.

more /etc/selinux/mls/contexts/securetty_contexts
sysadm_tty_device_t
staff_tty_device_t
user_tty_device_t



[-- Attachment #2: libselinux-rhat.patch --]
[-- Type: text/x-patch, Size: 8487 bytes --]

diff --exclude-from=exclude -N -u -r nsalibselinux/include/selinux/selinux.h libselinux-1.33.3/include/selinux/selinux.h
--- nsalibselinux/include/selinux/selinux.h	2006-11-16 17:15:18.000000000 -0500
+++ libselinux-1.33.3/include/selinux/selinux.h	2007-01-05 11:57:44.000000000 -0500
@@ -406,6 +406,7 @@
 	extern const char *selinux_homedir_context_path(void);
 	extern const char *selinux_media_context_path(void);
 	extern const char *selinux_contexts_path(void);
+	extern const char *selinux_securetty_context_path(void);
 	extern const char *selinux_booleans_path(void);
 	extern const char *selinux_customizable_types_path(void);
 	extern const char *selinux_users_path(void);
@@ -413,12 +414,14 @@
 	extern const char *selinux_translations_path(void);
 	extern const char *selinux_netfilter_context_path(void);
 	extern const char *selinux_path(void);
-
 /* Check a permission in the passwd class.
    Return 0 if granted or -1 otherwise. */
 	extern int selinux_check_passwd_access(access_vector_t requested);
 	extern int checkPasswdAccess(access_vector_t requested);
 
+/* Check if the tty_context is defined as a securetty
+   Return 1 if secure, 0 if not, or -1 if otherwise. */
+	extern int selinux_check_securetty_context(security_context_t tty_context);
 /* Set the path to the selinuxfs mount point explicitly.
    Normally, this is determined automatically during libselinux 
    initialization, but this is not always possible, e.g. for /sbin/init
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_binary_policy_path.3 libselinux-1.33.3/man/man3/selinux_binary_policy_path.3
--- nsalibselinux/man/man3/selinux_binary_policy_path.3	2006-11-16 17:15:30.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_binary_policy_path.3	2007-01-05 11:57:44.000000000 -0500
@@ -27,6 +27,8 @@
 .br
 extern const char *selinux_media_context_path(void);
 .br
+extern const char *selinux_securetty_context_path(void);
+.br
 extern const char *selinux_contexts_path(void);
 .br
 extern const char *selinux_booleans_path(void);
@@ -56,6 +58,8 @@
 .sp
 selinux_contexts_path() - directory containing all of the context configuration files
 .sp
+selinux_securetty_context_path() - defines terminal contexts for securetty
+.sp
 selinux_booleans_path() - initial policy boolean settings
 
 .SH AUTHOR	
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_check_securetty_context.3 libselinux-1.33.3/man/man3/selinux_check_securetty_context.3
--- nsalibselinux/man/man3/selinux_check_securetty_context.3	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_check_securetty_context.3	2007-01-05 11:57:44.000000000 -0500
@@ -0,0 +1,13 @@
+.TH "selinux_check_securetty_context" "3" "1 January 2007" "dwalsh@redhat.com" "SE Linux API documentation"
+.SH "NAME"
+selinux_check_securetty_context \- check whether a tty security context is defined as a securetty context
+.SH "SYNOPSIS"
+.B #include <selinux/selinux.h>
+.sp
+.BI "int selinux_check_securetty_context(security_context_t "tty_context );
+
+.SH "DESCRIPTION"
+.B selinux_check_securetty_context
+returns 1 if tty_context is a securetty context
+returns 0 if tty_context is a not a securetty context
+returns -1 on error.
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man3/selinux_securetty_context_path.3 libselinux-1.33.3/man/man3/selinux_securetty_context_path.3
--- nsalibselinux/man/man3/selinux_securetty_context_path.3	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/man/man3/selinux_securetty_context_path.3	2007-01-05 11:57:44.000000000 -0500
@@ -0,0 +1 @@
+.so man3/selinux_binary_policy_path.3
diff --exclude-from=exclude -N -u -r nsalibselinux/src/file_path_suffixes.h libselinux-1.33.3/src/file_path_suffixes.h
--- nsalibselinux/src/file_path_suffixes.h	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/file_path_suffixes.h	2007-01-05 11:57:44.000000000 -0500
@@ -7,6 +7,7 @@
     S_(USER_CONTEXTS, "/contexts/users/")
     S_(FAILSAFE_CONTEXT, "/contexts/failsafe_context")
     S_(DEFAULT_TYPE, "/contexts/default_type")
+    S_(SECURETTY_CONTEXTS, "/contexts/securetty_contexts")
     S_(BOOLEANS, "/booleans")
     S_(MEDIA_CONTEXTS, "/contexts/files/media")
     S_(REMOVABLE_CONTEXT, "/contexts/removable_context")
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_check_securetty_context.c libselinux-1.33.3/src/selinux_check_securetty_context.c
--- nsalibselinux/src/selinux_check_securetty_context.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/src/selinux_check_securetty_context.c	2007-01-05 11:57:44.000000000 -0500
@@ -0,0 +1,49 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <ctype.h>
+#include "selinux_internal.h"
+#include "context_internal.h"
+
+int selinux_check_securetty_context(security_context_t tty_context)
+{
+	char buf[250];
+	char *ptr = "", *end;
+	size_t len;
+	int found = -1;
+	FILE *fp;
+	fp = fopen(selinux_securetty_context_path(), "r");
+	if (fp) {
+		context_t con =context_new(tty_context);
+		if (con) {
+			char *type=context_type_get(con);
+			found = 0;
+			len = strlen(type);
+			while (!feof_unlocked(fp)) {
+				if (!fgets_unlocked(buf, sizeof buf, fp))
+					break;
+
+				if (buf[strlen(buf) - 1])
+					buf[strlen(buf) - 1] = 0;
+
+				ptr = buf;
+				while (*ptr && isspace(*ptr))
+					ptr++;
+				if (!(*ptr))
+					continue;
+
+				if (!strncmp(type, ptr, len)) {
+					found = 1;
+					break;
+				}
+			}
+			context_free(con);
+		}
+		fclose(fp);
+	}
+
+	return found;
+}
+
+hidden_def(selinux_check_securetty_context)
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_config.c libselinux-1.33.3/src/selinux_config.c
--- nsalibselinux/src/selinux_config.c	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/selinux_config.c	2007-01-05 11:57:44.000000000 -0500
@@ -38,7 +38,8 @@
 #define NETFILTER_CONTEXTS    15
 #define FILE_CONTEXTS_HOMEDIR 16
 #define FILE_CONTEXTS_LOCAL 17
-#define NEL               18
+#define SECURETTY_CONTEXTS  18
+#define NEL               19
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -299,6 +300,12 @@
 
 hidden_def(selinux_default_context_path)
 
+const char *selinux_securetty_context_path()
+{
+	return get_path(SECURETTY_CONTEXTS);
+}
+hidden_def(selinux_securetty_context_path)
+
 const char *selinux_failsafe_context_path()
 {
 	return get_path(FAILSAFE_CONTEXT);
diff --exclude-from=exclude -N -u -r nsalibselinux/src/selinux_internal.h libselinux-1.33.3/src/selinux_internal.h
--- nsalibselinux/src/selinux_internal.h	2006-11-16 17:15:25.000000000 -0500
+++ libselinux-1.33.3/src/selinux_internal.h	2007-01-05 11:57:44.000000000 -0500
@@ -53,6 +53,7 @@
     hidden_proto(security_setenforce)
     hidden_proto(selinux_binary_policy_path)
     hidden_proto(selinux_default_context_path)
+    hidden_proto(selinux_securetty_context_path)
     hidden_proto(selinux_failsafe_context_path)
     hidden_proto(selinux_removable_context_path)
     hidden_proto(selinux_file_context_path)
@@ -66,6 +67,7 @@
     hidden_proto(selinux_media_context_path)
     hidden_proto(selinux_path)
     hidden_proto(selinux_check_passwd_access)
+    hidden_proto(selinux_check_securetty_context)
     hidden_proto(matchpathcon_init_prefix)
     hidden_proto(selinux_users_path)
     hidden_proto(selinux_usersconf_path);
diff --exclude-from=exclude -N -u -r nsalibselinux/utils/selinux_check_securetty_context.c libselinux-1.33.3/utils/selinux_check_securetty_context.c
--- nsalibselinux/utils/selinux_check_securetty_context.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.33.3/utils/selinux_check_securetty_context.c	2007-01-05 11:57:44.000000000 -0500
@@ -0,0 +1,40 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <getopt.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/errno.h>
+#include <selinux/selinux.h>
+
+void usage(const char *progname)
+{
+	fprintf(stderr,
+		"usage:  %s tty_context...\n",
+		progname);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	int i;
+	if (argc < 2)
+		usage(argv[0]);
+
+	for (i = 1; i < argc; i++) {
+		switch (selinux_check_securetty_context(argv[i])) {
+		case 1:
+			printf("%s securetty.\n", argv[i]);
+			break;
+		case 0:
+			printf("%s not securetty.\n", argv[i]);
+			break;
+		case -1:
+			perror("Failed on check if securetty");
+			return -1;
+		}
+	}
+	return 0;
+}

Re: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Fri, 2007-01-05 at 12:05 -0500, Daniel J Walsh wrote:
> First libselinux-rhat patch was broken.  Needs to only check the context 
> type.
> 
> more /etc/selinux/mls/contexts/securetty_contexts
> sysadm_tty_device_t
> staff_tty_device_t
> user_tty_device_t

Use getline() instead of fgets() to gain the benefit of automatically
allocated buffers.  See init_selinux_config() for example.
-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Fri, 2007-01-05 at 11:24 -0500, Daniel J Walsh wrote:
> newrole patch. for checking securetty.
> 
> 
> diff --exclude-from=exclude --exclude POTFILES.in --exclude='*.po' 
> --exclude='*.pot' -N -u -r nsapolicycoreutils/newrole/newrole.c 
> policycoreutils-1.33.8/newrole/newrole.c
> --- nsapolicycoreutils/newrole/newrole.c        2007-01-04 
> 17:01:41.000000000 -0500
> +++ policycoreutils-1.33.8/newrole/newrole.c    2007-01-05 
> 11:17:36.000000000 -0500
> @@ -793,6 +797,18 @@
>                                         "specified\n"));
>                                 return -1;
>                         }
> +                       for (i=0; i < 3; i++) {
> +                               securetty=0;
> +                               if (fgetfilecon(i,&tty_con) >= 0) {
> +                                       securetty = 
> (selinux_check_securetty_context(tty_con) == 1);
> +                                       freecon(tty_con);
> +                               }
> +                               if (!securetty) {
> +                                       fprintf(stderr, "Error: you are 
> not allowed to change levels on a non secure terminal\n");
> +                                       return -1;
> +                               }
> +                       }
> +
>                         level_s = optarg;
>                         break;
>                 default:
> 

Aside from whitespace damage, do we need to check all three descriptors?
newrole only calls ttyname(0) and then re-opens that on all three
descriptors, so even if 1 and 2 point to something else, they would be
ignored (never relabeled, just closed).  So I would think you would only
need to check descriptor 0.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2007-01-04 at 22:35 -0500, Joshua Brindle wrote:
> > From: Klaus Weidner [mailto:klaus@atsec.com] 
> > 
> > On Thu, Jan 04, 2007 at 10:05:57PM -0500, Joshua Brindle wrote:
> > > Hardcoding types into code makes it inflexible to policy 
> > changes, this 
> > > is a bad idea IMO, the tty whitelist, however, is probably 
> > the way to 
> > > go. I don't know if we should use the existing 
> > /etc/securetty or  add 
> > > our own file though.
> > 
> > I'm not sure if the existing /etc/securetty is the right one, 
> > since people may make serial terminals available to users but 
> > would not want direct root login on those. Well, maybe not 
> > terribly likely these days.
> > 
> > Instead of hardcoded types, how about a configurable type or 
> > a /etc/securettytypes file that contains the types instead of 
> > tty names?
> 
> Sure, the securettycontexts might be the way to go. I'm dubious about
> just making this happen for level changes though, you shouldn't be able
> to bypass any part of the security policy using newrole.

We don't want to break newrole -r on a pty.  

(issue is that there are two ends for a pty, master and slave, and only
the slave end is relabeled by newrole.  master end is always /dev/ptmx
wrt the inode, only the open file is per instance IIUC).

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> We still have a problem on MLS machines, in that
> newrole can be used to 
> pass data via pseudo terminals.
> 
> script
> newrole -l SystemHigh
> cat TopSecret.doc
> ^d
> ^d
> cat typescript
> 
> I propose we add this patch to newrole to check if
> we are on a pseudo 
> terminal and then fail if user is using -l.
> 
> Basically this patch checks the major number of the
> stdin, stdout, 
> stderr for a number in the pseudo number range,  If
> yes the pseudo 
> terminal, if not continue.  Not pretty but it solves
> the problem.  I 
> could not figure out another way to check if you are
> on a pseudo terminal. 
> 
> Comments?

Are you 100% certain that this is only a pty
issue? Any chance you'll have a similar problem
with other devices, pipes, fifos, UDS or the like?
My pair of Lincolns says otherwise, but they've
been wrong before.


Casey Schaufler
casey@schaufler-ca.com

--
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: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

Casey Schaufler wrote:
> --- Daniel J Walsh <dwalsh@redhat.com> wrote:
>
>   
>> We still have a problem on MLS machines, in that
>> newrole can be used to 
>> pass data via pseudo terminals.
>>
>> script
>> newrole -l SystemHigh
>> cat TopSecret.doc
>> ^d
>> ^d
>> cat typescript
>>
>> I propose we add this patch to newrole to check if
>> we are on a pseudo 
>> terminal and then fail if user is using -l.
>>
>> Basically this patch checks the major number of the
>> stdin, stdout, 
>> stderr for a number in the pseudo number range,  If
>> yes the pseudo 
>> terminal, if not continue.  Not pretty but it solves
>> the problem.  I 
>> could not figure out another way to check if you are
>> on a pseudo terminal. 
>>
>> Comments?
>>     
>
> Are you 100% certain that this is only a pty
> issue? Any chance you'll have a similar problem
> with other devices, pipes, fifos, UDS or the like?
> My pair of Lincolns says otherwise, but they've
> been wrong before.
>
>
>   
That would probably be a fools bet.  There are other checks in newrole 
to make sure it is talking to a terminal, though.  I worry that I have 
hit all the pseudo terminals though.  I am hoping others smarter then me 
in the kernel would know.
> Casey Schaufler
> casey@schaufler-ca.com
>   



--
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: [PATCH 1/3] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Mon, 2006-10-30 at 15:03 -0500, James Antill wrote:
> On Fri, 2006-10-27 at 14:38 -0400, Stephen Smalley wrote:
> 
> > Look at Darrel's patch for mcstransd to apply a permission check between
> > the level of the caller and the level being translated for context
> > translations. 
> 
>  Thanks to much discussion with Dan and Stephen, I'm pretty sure I have
> this correct now.
> 
>  Here is the libselinux part of the patch (reference policy and PAM are
> next).

transition is a bit misleading as a name - you are checking a contains
relationship between two contexts, not transitioning between them.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Wed, 2006-10-25 at 15:15 -0400, James Antill wrote:
> On Wed, 2006-10-25 at 09:59 -0400, Stephen Smalley wrote:
> > On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> > >  My understanding is that while security_check_context() allows it, the
> > > setexeccon() will fail. Which seemed to be good enough.
> > 
> > No, it won't.  Suppose that I have two Linux users A and B, with A
> > authorized for category c0 and B authorized for category c2 in seusers,
> > but both A and B are mapped to SELinux user U who is authorized for all
> > categories in the kernel policy.  The login-style programs are naturally
> > going to be authorized to transition to any of those contexts since they
> > have to deal with user logins at any level, so the setexeccon() will
> > succeed.  The SELinux security context will have U as the user identity,
> > so it will always be valid.  You need an explicit check.
> 
>  Ok, I had assumed that "U" would always be different in this case.

BTW, using different SELinux user identities (U) was the approach before
seusers came into being, but the point of seusers was to avoid having to
rebuild the kernel policy every time you wanted to add, remove, or
change a Linux user's authorized range.  Thus, the per-Linux-user
restriction is specified in seusers and enforced by the login-style
programs (and then subsequently bounded for the session based on the
high/clearance level).

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Daniel J Walsh]

Stephen Smalley wrote:
> On Wed, 2006-10-25 at 15:15 -0400, James Antill wrote:
>   
>> On Wed, 2006-10-25 at 09:59 -0400, Stephen Smalley wrote:
>>     
>>> On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
>>>       
>>>>  My understanding is that while security_check_context() allows it, the
>>>> setexeccon() will fail. Which seemed to be good enough.
>>>>         
>>> No, it won't.  Suppose that I have two Linux users A and B, with A
>>> authorized for category c0 and B authorized for category c2 in seusers,
>>> but both A and B are mapped to SELinux user U who is authorized for all
>>> categories in the kernel policy.  The login-style programs are naturally
>>> going to be authorized to transition to any of those contexts since they
>>> have to deal with user logins at any level, so the setexeccon() will
>>> succeed.  The SELinux security context will have U as the user identity,
>>> so it will always be valid.  You need an explicit check.
>>>       
>>  Ok, I had assumed that "U" would always be different in this case.
>>     
>
> BTW, using different SELinux user identities (U) was the approach before
> seusers came into being, but the point of seusers was to avoid having to
> rebuild the kernel policy every time you wanted to add, remove, or
> change a Linux user's authorized range.  Thus, the per-Linux-user
> restriction is specified in seusers and enforced by the login-style
> programs (and then subsequently bounded for the session based on the
> high/clearance level).
>   

I think the same check should be added to the cron patch also.



--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Steve Grubb]

On Thursday 19 October 2006 09:21, Daniel J Walsh wrote:
> If we then remove -l from newrole we are done?

And would doing this also mean we do not need to add pam_namespace to newrole?

-Steve

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2006-10-19 at 09:32 -0400, Steve Grubb wrote:
> On Thursday 19 October 2006 09:21, Daniel J Walsh wrote:
> > If we then remove -l from newrole we are done?
> 
> And would doing this also mean we do not need to add pam_namespace to newrole?

Well, some people want pam_namespace functionality for roles, not just
levels.

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Russell Coker]

On Thursday 19 October 2006 23:21, Daniel J Walsh <dwalsh@redhat.com> wrote:
> If we then remove -l from newrole we are done?

Why remove it?  Why not just cease using it and leave it there for other 
people who have different needs?

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Fri, 20 Oct 2006 17:00:28 +1000, Russell Coker said:
> On Thursday 19 October 2006 23:21, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > If we then remove -l from newrole we are done?
> 
> Why remove it?  Why not just cease using it and leave it there for other 
> people who have different needs?

I suspect that it wouldn't fly during an eval, because even if unused, it
would be a possible avenue to bypass the evel'ed config.  You'd probably
have to add a flag of some sort someplace that said if it was permitted.
(If done inside PAM, having the .so have an option 'allow-dash-l' and
submitting for eval with it not present would probably be OK).

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Russell Coker]

On Saturday 28 October 2006 01:36, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 20 Oct 2006 17:00:28 +1000, Russell Coker said:
> > On Thursday 19 October 2006 23:21, Daniel J Walsh <dwalsh@redhat.com> 
wrote:
> > > If we then remove -l from newrole we are done?
> >
> > Why remove it?  Why not just cease using it and leave it there for other
> > people who have different needs?
>
> I suspect that it wouldn't fly during an eval, because even if unused, it

OK.

Well #if 0 would still be better than removing the code.  This is something we 
may want to resurrect at a later time.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: [redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Sat, 2006-10-28 at 09:04 +1000, Russell Coker wrote:
> On Saturday 28 October 2006 01:36, Valdis.Kletnieks@vt.edu wrote:
> > On Fri, 20 Oct 2006 17:00:28 +1000, Russell Coker said:
> > > On Thursday 19 October 2006 23:21, Daniel J Walsh <dwalsh@redhat.com> 
> wrote:
> > > > If we then remove -l from newrole we are done?
> > >
> > > Why remove it?  Why not just cease using it and leave it there for other
> > > people who have different needs?
> >
> > I suspect that it wouldn't fly during an eval, because even if unused, it
> 
> OK.
> 
> Well #if 0 would still be better than removing the code.  This is something we 
> may want to resurrect at a later time.

It isn't being removed, at least not upstream.

-- 
Stephen Smalley
National Security Agency


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