FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 05-15-2008, 05:11 PM
Tomas Mraz
 
Default Differences between openssh and pam_selinux

There are some differences in how openssh and pam_selinux get the user's
context. As I want to replace part of the openssh's SELinux code with
pam_selinux I'd like to know which one is more correct.

Here's the rough algorithm for both:

OpenSSH
=======

1. get selinux user & default level with getseuserbyname()
2. obtain default ctx with get_default_context_with_level()
3. obtain requested ctx for requested level with
get_default_context_with_level()
4. set requested role to the requested ctx
5. set type for the requested role to the requested ctx (obtained from
get_default_type(requested role))
6. copy the requested ctx and set the requested level in the copy
7. compare the requested ctx with the copy - if not equal -> fail
8. do the points 3. - 7. with the difference that the default level is
used instead of requested level
9. do security_compute_av with CONTEXT__CONTAINS to check whether the
context from 7. is allowed for context from 8. if not allowed -> fail
10. use the context from 7. as the user's context.

pam_selinux
===========

1. get selinux user & default level with getseuserbyname()
2. use get_ordered_context_list_with_level() to obtain list of context
for the user & level, as the default user's context is taken the first
one on the list
3. if this fails:
3a. the level and role is obtained from user and combined into a
context with default type for the role and the selinux user
3b. this ctx is checked with security_check_context() - if fails ->
fail else we have the user's context -> end
4. if 2. succeeds and module is configured to allow asking user for
role/level then user is asked for requested role and level
5. the requested ctx starts as copy of the default ctx
6. the requested role is set to requested ctx, requested level is set
and the default type (get_default_type()) for the requested role is set
7. the requested ctx is checked with security_check_context() - if fails
-> fail
8. do security_compute_av with CONTEXT__CONTAINS to check whether the
context from 7. is allowed for default context if not allowed -> fail
9. use the context from 7. as the user's context.

So which one is correct if any?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-16-2008, 03:08 PM
Stephen Smalley
 
Default Differences between openssh and pam_selinux

On Thu, 2008-05-15 at 19:11 +0200, Tomas Mraz wrote:
> There are some differences in how openssh and pam_selinux get the user's
> context. As I want to replace part of the openssh's SELinux code with
> pam_selinux I'd like to know which one is more correct.
>
> Here's the rough algorithm for both:
>
> OpenSSH
> =======
>
> 1. get selinux user & default level with getseuserbyname()
> 2. obtain default ctx with get_default_context_with_level()
> 3. obtain requested ctx for requested level with
> get_default_context_with_level()
> 4. set requested role to the requested ctx
> 5. set type for the requested role to the requested ctx (obtained from
> get_default_type(requested role))
> 6. copy the requested ctx and set the requested level in the copy
> 7. compare the requested ctx with the copy - if not equal -> fail
> 8. do the points 3. - 7. with the difference that the default level is
> used instead of requested level
> 9. do security_compute_av with CONTEXT__CONTAINS to check whether the
> context from 7. is allowed for context from 8. if not allowed -> fail
> 10. use the context from 7. as the user's context.
>
> pam_selinux
> ===========
>
> 1. get selinux user & default level with getseuserbyname()
> 2. use get_ordered_context_list_with_level() to obtain list of context
> for the user & level, as the default user's context is taken the first
> one on the list
> 3. if this fails:
> 3a. the level and role is obtained from user and combined into a
> context with default type for the role and the selinux user
> 3b. this ctx is checked with security_check_context() - if fails ->
> fail else we have the user's context -> end
> 4. if 2. succeeds and module is configured to allow asking user for
> role/level then user is asked for requested role and level
> 5. the requested ctx starts as copy of the default ctx
> 6. the requested role is set to requested ctx, requested level is set
> and the default type (get_default_type()) for the requested role is set
> 7. the requested ctx is checked with security_check_context() - if fails
> -> fail
> 8. do security_compute_av with CONTEXT__CONTAINS to check whether the
> context from 7. is allowed for default context if not allowed -> fail
> 9. use the context from 7. as the user's context.
>
> So which one is correct if any?

(cc'ing selinux@tycho.nsa.gov as this is an upstream issue as well)

The logic has evolved or perhaps devolved over time (e.g. introduction
of seusers as a further level of indirection between Linux users and
SELinux users, introduction of support for requesting specific roles and
levels), and we really ought to try to encapsulate more of it within a
single libselinux helper function that can be used by all applications.

As I recall, openssh had special logic introduced to preserve the
desired LSPP behavior for labeled networking (ensuring that the client's
level is preserved across the entire session as otherwise data would be
downgraded from the server to the client). That may explain the
difference. In that scenario, as I recall, xinetd would launch sshd in
the level obtained for the client via getpeercon.

Abstractly, we want the final context (user:role:type:level) that is
used to:
1) use the SELinux user obtained from getseuserbyname(),
2) have valid user-role, role-type, and user-level pairs (this will in
fact be checked by the kernel upon attempted use to setexeccon(), but
we'd rather catch it early via security_check_context),
3) be bounded (via CONTEXT__CONTAINS check) by the MLS level or range
for the Linux user obtained from getseuserbyname() as this may be a
subset of the range authorized for the SELinux user, and
4) be bounded by the MLS range of the caller (this is especially for the
labeled networking case, but is generally true and could be useful even
for local logins e.g. to bind a specific range to one tty and a
different range to another).

get_default_context* internally just uses get_ordered_context* and then
selects the first item, so there is no difference between using them if
you are only selecting the first item. The only reason to use
get_ordered_context* is if you want to present a list of options to the
user for selection, which pam_selinux did at one time.

Possibly we want a libselinux interface that takes the Linux username,
an optional requested role and an optional requested level argument, and
just returns an entire context that meets the criteria above.
getseuserbyname() can be used to obtain the default values of the
SELinux user and the range/level for the context. If no role was
requested, it could be obtained via get_default_context although it
would be nice to just provide a simpler mechanism specialized for that
purpose, e.g. a policy config file that maps SELinux users to default
roles (Chris cc'd). The type could always default to get_default_type()
for the role in that case, thereby eliminating any chance of incorrectly
getting any program types there.

Thoughts?

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 05-16-2008, 03:25 PM
Stephen Smalley
 
Default Differences between openssh and pam_selinux

On Fri, 2008-05-16 at 11:08 -0400, Stephen Smalley wrote:
> On Thu, 2008-05-15 at 19:11 +0200, Tomas Mraz wrote:
> > There are some differences in how openssh and pam_selinux get the user's
> > context. As I want to replace part of the openssh's SELinux code with
> > pam_selinux I'd like to know which one is more correct.
> >
> > Here's the rough algorithm for both:
> >
> > OpenSSH
> > =======
> >
> > 1. get selinux user & default level with getseuserbyname()
> > 2. obtain default ctx with get_default_context_with_level()
> > 3. obtain requested ctx for requested level with
> > get_default_context_with_level()
> > 4. set requested role to the requested ctx
> > 5. set type for the requested role to the requested ctx (obtained from
> > get_default_type(requested role))
> > 6. copy the requested ctx and set the requested level in the copy
> > 7. compare the requested ctx with the copy - if not equal -> fail
> > 8. do the points 3. - 7. with the difference that the default level is
> > used instead of requested level
> > 9. do security_compute_av with CONTEXT__CONTAINS to check whether the
> > context from 7. is allowed for context from 8. if not allowed -> fail
> > 10. use the context from 7. as the user's context.
> >
> > pam_selinux
> > ===========
> >
> > 1. get selinux user & default level with getseuserbyname()
> > 2. use get_ordered_context_list_with_level() to obtain list of context
> > for the user & level, as the default user's context is taken the first
> > one on the list
> > 3. if this fails:
> > 3a. the level and role is obtained from user and combined into a
> > context with default type for the role and the selinux user
> > 3b. this ctx is checked with security_check_context() - if fails ->
> > fail else we have the user's context -> end
> > 4. if 2. succeeds and module is configured to allow asking user for
> > role/level then user is asked for requested role and level
> > 5. the requested ctx starts as copy of the default ctx
> > 6. the requested role is set to requested ctx, requested level is set
> > and the default type (get_default_type()) for the requested role is set
> > 7. the requested ctx is checked with security_check_context() - if fails
> > -> fail
> > 8. do security_compute_av with CONTEXT__CONTAINS to check whether the
> > context from 7. is allowed for default context if not allowed -> fail
> > 9. use the context from 7. as the user's context.
> >
> > So which one is correct if any?
>
> (cc'ing selinux@tycho.nsa.gov as this is an upstream issue as well)
>
> The logic has evolved or perhaps devolved over time (e.g. introduction
> of seusers as a further level of indirection between Linux users and
> SELinux users, introduction of support for requesting specific roles and
> levels), and we really ought to try to encapsulate more of it within a
> single libselinux helper function that can be used by all applications.
>
> As I recall, openssh had special logic introduced to preserve the
> desired LSPP behavior for labeled networking (ensuring that the client's
> level is preserved across the entire session as otherwise data would be
> downgraded from the server to the client). That may explain the
> difference. In that scenario, as I recall, xinetd would launch sshd in
> the level obtained for the client via getpeercon.
>
> Abstractly, we want the final context (user:role:type:level) that is
> used to:
> 1) use the SELinux user obtained from getseuserbyname(),
> 2) have valid user-role, role-type, and user-level pairs (this will in
> fact be checked by the kernel upon attempted use to setexeccon(), but
> we'd rather catch it early via security_check_context),
> 3) be bounded (via CONTEXT__CONTAINS check) by the MLS level or range
> for the Linux user obtained from getseuserbyname() as this may be a
> subset of the range authorized for the SELinux user, and
> 4) be bounded by the MLS range of the caller (this is especially for the
> labeled networking case, but is generally true and could be useful even
> for local logins e.g. to bind a specific range to one tty and a
> different range to another).
>
> get_default_context* internally just uses get_ordered_context* and then
> selects the first item, so there is no difference between using them if
> you are only selecting the first item. The only reason to use
> get_ordered_context* is if you want to present a list of options to the
> user for selection, which pam_selinux did at one time.
>
> Possibly we want a libselinux interface that takes the Linux username,
> an optional requested role and an optional requested level argument, and
> just returns an entire context that meets the criteria above.
> getseuserbyname() can be used to obtain the default values of the
> SELinux user and the range/level for the context. If no role was
> requested, it could be obtained via get_default_context although it
> would be nice to just provide a simpler mechanism specialized for that
> purpose, e.g. a policy config file that maps SELinux users to default
> roles (Chris cc'd). The type could always default to get_default_type()
> for the role in that case, thereby eliminating any chance of incorrectly
> getting any program types there.

Ah, a limitation of the "simpler" approach described above is that it
doesn't allow the context-sensitive selection of default roles and types
that is presently supported by get_default_context*. For example, at
present, we can make root's default login role sysadm_r if on the
console but staff_r if via gdm or sshd (based on the context of the
caller/login process), and we can make the default type vary depending
on the caller as well, such that we could use the derived domains for
cron jobs. So perhaps in the short term we'll need to keep using
get_default_context* internally but we might be able to replace it in
the future.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 10:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org