matchpathcon() for arbitrary subjects

matchpathcon() for arbitrary subjects

[Matt Anderson]

I'm trying to get the CUPS print server to print to a file on the file
system.  In order to do this in a usable way I want to be able to query
the SELinux security server as to what the type of a file would be for a
given directory.  This is essentially what matchpathcon() does, and I
can get that to work.

The part I'm having trouble with is I'm making this call from cupsd with
the context of system_u:system_r:cupsd_t:SystemHigh and getting a
response for that type.  I'd like to make the call from that context,
but asking the server what the result would be for a given user's
context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
with some other existing function?

-matt

--
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
> I'm trying to get the CUPS print server to print to a file on the file
> system.  In order to do this in a usable way I want to be able to query
> the SELinux security server as to what the type of a file would be for a
> given directory.  This is essentially what matchpathcon() does, and I
> can get that to work.
> 
> The part I'm having trouble with is I'm making this call from cupsd with
> the context of system_u:system_r:cupsd_t:SystemHigh and getting a
> response for that type.  I'd like to make the call from that context,
> but asking the server what the result would be for a given user's
> context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
> with some other existing function?

matchpathcon() doesn't consult the security server; it just performs
pathname matching against the file contexts configuration, which
expresses the install-time labeling information for initially labeling
files when they are installed from an external source (like a package)
or for restoring them to those initial labels.  Thus, it isn't relative
to a subject in any way.  It is only used by applications, not the
kernel.

security_compute_create() is an interface to the security server for
computing a runtime labeling decision based on a subject label, a
related object label (e.g. parent directory), and an object class (e.g.
SECCLASS_FILE).  An internal form of this interface is used by the
kernel to determine how to label newly created files by default.

But I'm not entirely clear on what you are trying to do here - you want
the cups daemon to write to a file that will then be accessible to the
client which requested the print job?  In a possibly user (or otherwise
untrusted)-writable directory?  That begs for security problems.

-- 
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 14:40 -0500, Stephen Smalley wrote:
> On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
> > I'm trying to get the CUPS print server to print to a file on the file
> > system.  In order to do this in a usable way I want to be able to query
> > the SELinux security server as to what the type of a file would be for a
> > given directory.  This is essentially what matchpathcon() does, and I
> > can get that to work.
> > 
> > The part I'm having trouble with is I'm making this call from cupsd with
> > the context of system_u:system_r:cupsd_t:SystemHigh and getting a
> > response for that type.  I'd like to make the call from that context,
> > but asking the server what the result would be for a given user's
> > context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
> > with some other existing function?
> 
> matchpathcon() doesn't consult the security server; it just performs
> pathname matching against the file contexts configuration, which
> expresses the install-time labeling information for initially labeling
> files when they are installed from an external source (like a package)
> or for restoring them to those initial labels.  Thus, it isn't relative
> to a subject in any way.  It is only used by applications, not the
> kernel.
> 
> security_compute_create() is an interface to the security server for
> computing a runtime labeling decision based on a subject label, a
> related object label (e.g. parent directory), and an object class (e.g.
> SECCLASS_FILE).  An internal form of this interface is used by the
> kernel to determine how to label newly created files by default.
> 
> But I'm not entirely clear on what you are trying to do here - you want
> the cups daemon to write to a file that will then be accessible to the
> client which requested the print job?  In a possibly user (or otherwise
> untrusted)-writable directory?  That begs for security problems.

Why can't cupsd just generate the output to a socket back to the client,
and let the client write it out to a file?  Then you don't need any
special logic in cupsd for labeling of the file, nor any confused deputy
issues (e.g. client tricking cupsd into creating a file in a location
that wouldn't normally be accessible to the client).

-- 
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: matchpathcon() for arbitrary subjects

[Matt Anderson]

Stephen Smalley wrote:
> On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
>> I'm trying to get the CUPS print server to print to a file on the file
>> system.  In order to do this in a usable way I want to be able to query
>> the SELinux security server as to what the type of a file would be for a
>> given directory.  This is essentially what matchpathcon() does, and I
>> can get that to work.
>>
>> The part I'm having trouble with is I'm making this call from cupsd with
>> the context of system_u:system_r:cupsd_t:SystemHigh and getting a
>> response for that type.  I'd like to make the call from that context,
>> but asking the server what the result would be for a given user's
>> context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
>> with some other existing function?
> 
> matchpathcon() doesn't consult the security server; it just performs
> pathname matching against the file contexts configuration, which
> expresses the install-time labeling information for initially labeling
> files when they are installed from an external source (like a package)
> or for restoring them to those initial labels.  Thus, it isn't relative
> to a subject in any way.  It is only used by applications, not the
> kernel.
> 
> security_compute_create() is an interface to the security server for
> computing a runtime labeling decision based on a subject label, a
> related object label (e.g. parent directory), and an object class (e.g.
> SECCLASS_FILE).  An internal form of this interface is used by the
> kernel to determine how to label newly created files by default.
> 
> But I'm not entirely clear on what you are trying to do here - you want
> the cups daemon to write to a file that will then be accessible to the
> client which requested the print job?  In a possibly user (or otherwise
> untrusted)-writable directory?  That begs for security problems.

Its not quite that bad.  First the destination file is a predetermined
path as configured by the cups administrator.  Secondly if the file does
already exist avc_has_perm() is called to see if the client's context
has write privileges to it before the job is accepted, or printed.

The problem I'm trying to solve is how do you keep file printers in a
useful way with SELinux?  If the output file is a single type then
secadm and a user could both print to it and read from it which is a
problem.  If cupsd queries the security server then type_transition
rules could be used to specify what the type should be based on who
supplied the print job.

-matt

--
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 15:46 -0500, Matt Anderson wrote:
> Stephen Smalley wrote:
> > On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
> >> I'm trying to get the CUPS print server to print to a file on the file
> >> system.  In order to do this in a usable way I want to be able to query
> >> the SELinux security server as to what the type of a file would be for a
> >> given directory.  This is essentially what matchpathcon() does, and I
> >> can get that to work.
> >>
> >> The part I'm having trouble with is I'm making this call from cupsd with
> >> the context of system_u:system_r:cupsd_t:SystemHigh and getting a
> >> response for that type.  I'd like to make the call from that context,
> >> but asking the server what the result would be for a given user's
> >> context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
> >> with some other existing function?
> > 
> > matchpathcon() doesn't consult the security server; it just performs
> > pathname matching against the file contexts configuration, which
> > expresses the install-time labeling information for initially labeling
> > files when they are installed from an external source (like a package)
> > or for restoring them to those initial labels.  Thus, it isn't relative
> > to a subject in any way.  It is only used by applications, not the
> > kernel.
> > 
> > security_compute_create() is an interface to the security server for
> > computing a runtime labeling decision based on a subject label, a
> > related object label (e.g. parent directory), and an object class (e.g.
> > SECCLASS_FILE).  An internal form of this interface is used by the
> > kernel to determine how to label newly created files by default.
> > 
> > But I'm not entirely clear on what you are trying to do here - you want
> > the cups daemon to write to a file that will then be accessible to the
> > client which requested the print job?  In a possibly user (or otherwise
> > untrusted)-writable directory?  That begs for security problems.
> 
> Its not quite that bad.  First the destination file is a predetermined
> path as configured by the cups administrator.  Secondly if the file does
> already exist avc_has_perm() is called to see if the client's context
> has write privileges to it before the job is accepted, or printed.

Are any of the directories in that path (as typically configured)
user-writable?  Wouldn't you need per-context destination files?
Otherwise, it seems like that avc_has_perm() call is going to fail for
all subsequent subjects in any context other than the original creator's
context after the file is initially created. 

> The problem I'm trying to solve is how do you keep file printers in a
> useful way with SELinux?  If the output file is a single type then
> secadm and a user could both print to it and read from it which is a
> problem.  If cupsd queries the security server then type_transition
> rules could be used to specify what the type should be based on who
> supplied the print job.

security_compute_create() is turned into a security_transition_sid()
call in the kernel, which consults the type_transition rules.  So that
will give you the result you describe above.  But I don't understand how
that solves the sharing problem posed by the use of a file (unless you
create per-context destination files, effectively polyinstantiating
them), and I don't see why that is better than feeding the file back to
the client over a socket and letting the client write it to a file.

-- 
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 15:50 -0500, Stephen Smalley wrote:
> On Tue, 2006-12-12 at 15:46 -0500, Matt Anderson wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
> > >> I'm trying to get the CUPS print server to print to a file on the file
> > >> system.  In order to do this in a usable way I want to be able to query
> > >> the SELinux security server as to what the type of a file would be for a
> > >> given directory.  This is essentially what matchpathcon() does, and I
> > >> can get that to work.
> > >>
> > >> The part I'm having trouble with is I'm making this call from cupsd with
> > >> the context of system_u:system_r:cupsd_t:SystemHigh and getting a
> > >> response for that type.  I'd like to make the call from that context,
> > >> but asking the server what the result would be for a given user's
> > >> context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
> > >> with some other existing function?
> > > 
> > > matchpathcon() doesn't consult the security server; it just performs
> > > pathname matching against the file contexts configuration, which
> > > expresses the install-time labeling information for initially labeling
> > > files when they are installed from an external source (like a package)
> > > or for restoring them to those initial labels.  Thus, it isn't relative
> > > to a subject in any way.  It is only used by applications, not the
> > > kernel.
> > > 
> > > security_compute_create() is an interface to the security server for
> > > computing a runtime labeling decision based on a subject label, a
> > > related object label (e.g. parent directory), and an object class (e.g.
> > > SECCLASS_FILE).  An internal form of this interface is used by the
> > > kernel to determine how to label newly created files by default.
> > > 
> > > But I'm not entirely clear on what you are trying to do here - you want
> > > the cups daemon to write to a file that will then be accessible to the
> > > client which requested the print job?  In a possibly user (or otherwise
> > > untrusted)-writable directory?  That begs for security problems.
> > 
> > Its not quite that bad.  First the destination file is a predetermined
> > path as configured by the cups administrator.  Secondly if the file does
> > already exist avc_has_perm() is called to see if the client's context
> > has write privileges to it before the job is accepted, or printed.
> 
> Are any of the directories in that path (as typically configured)
> user-writable?  Wouldn't you need per-context destination files?
> Otherwise, it seems like that avc_has_perm() call is going to fail for
> all subsequent subjects in any context other than the original creator's
> context after the file is initially created. 
> 
> > The problem I'm trying to solve is how do you keep file printers in a
> > useful way with SELinux?  If the output file is a single type then
> > secadm and a user could both print to it and read from it which is a
> > problem.  If cupsd queries the security server then type_transition
> > rules could be used to specify what the type should be based on who
> > supplied the print job.
> 
> security_compute_create() is turned into a security_transition_sid()
> call in the kernel, which consults the type_transition rules.  So that
> will give you the result you describe above.  But I don't understand how
> that solves the sharing problem posed by the use of a file (unless you
> create per-context destination files, effectively polyinstantiating
> them), and I don't see why that is better than feeding the file back to
> the client over a socket and letting the client write it to a file.

Wait...do you actually want the files to be directly accessible to the
clients, or only accessible through the cups server?  If the latter,
then why create them in a context based on the client at all (versus
just putting them in a private type of cupsd and having it mediate all
subsequent access to 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.

Re: matchpathcon() for arbitrary subjects

[Matt Anderson]

Stephen Smalley wrote:
> On Tue, 2006-12-12 at 15:50 -0500, Stephen Smalley wrote:
>> On Tue, 2006-12-12 at 15:46 -0500, Matt Anderson wrote:
>>> Stephen Smalley wrote:
>>>> On Tue, 2006-12-12 at 14:21 -0500, Matt Anderson wrote:
>>>>> I'm trying to get the CUPS print server to print to a file on the file
>>>>> system.  In order to do this in a usable way I want to be able to query
>>>>> the SELinux security server as to what the type of a file would be for a
>>>>> given directory.  This is essentially what matchpathcon() does, and I
>>>>> can get that to work.
>>>>>
>>>>> The part I'm having trouble with is I'm making this call from cupsd with
>>>>> the context of system_u:system_r:cupsd_t:SystemHigh and getting a
>>>>> response for that type.  I'd like to make the call from that context,
>>>>> but asking the server what the result would be for a given user's
>>>>> context (such as user_u:user_r:user_lpr_t:SystemLow) is this possible
>>>>> with some other existing function?
>>>> matchpathcon() doesn't consult the security server; it just performs
>>>> pathname matching against the file contexts configuration, which
>>>> expresses the install-time labeling information for initially labeling
>>>> files when they are installed from an external source (like a package)
>>>> or for restoring them to those initial labels.  Thus, it isn't relative
>>>> to a subject in any way.  It is only used by applications, not the
>>>> kernel.
>>>>
>>>> security_compute_create() is an interface to the security server for
>>>> computing a runtime labeling decision based on a subject label, a
>>>> related object label (e.g. parent directory), and an object class (e.g.
>>>> SECCLASS_FILE).  An internal form of this interface is used by the
>>>> kernel to determine how to label newly created files by default.
>>>>
>>>> But I'm not entirely clear on what you are trying to do here - you want
>>>> the cups daemon to write to a file that will then be accessible to the
>>>> client which requested the print job?  In a possibly user (or otherwise
>>>> untrusted)-writable directory?  That begs for security problems.
>>> Its not quite that bad.  First the destination file is a predetermined
>>> path as configured by the cups administrator.  Secondly if the file does
>>> already exist avc_has_perm() is called to see if the client's context
>>> has write privileges to it before the job is accepted, or printed.
>> Are any of the directories in that path (as typically configured)
>> user-writable?  Wouldn't you need per-context destination files?
>> Otherwise, it seems like that avc_has_perm() call is going to fail for
>> all subsequent subjects in any context other than the original creator's
>> context after the file is initially created.

Thats true, once there was output it would block other users from using
that queue until it was removed.  This is intentional.

>>> The problem I'm trying to solve is how do you keep file printers in a
>>> useful way with SELinux?  If the output file is a single type then
>>> secadm and a user could both print to it and read from it which is a
>>> problem.  If cupsd queries the security server then type_transition
>>> rules could be used to specify what the type should be based on who
>>> supplied the print job.
>> security_compute_create() is turned into a security_transition_sid()
>> call in the kernel, which consults the type_transition rules.  So that
>> will give you the result you describe above.  But I don't understand how
>> that solves the sharing problem posed by the use of a file (unless you
>> create per-context destination files, effectively polyinstantiating
>> them), and I don't see why that is better than feeding the file back to
>> the client over a socket and letting the client write it to a file.
> 
> Wait...do you actually want the files to be directly accessible to the
> clients, or only accessible through the cups server?  If the latter,
> then why create them in a context based on the client at all (versus
> just putting them in a private type of cupsd and having it mediate all
> subsequent access to it)?  

The idea is to bring some sort of useful SELinux support to file
printers.  In the case of file printers I've taken this to mean that the
user who printed the job would be able to access the output directly.

Cups has no mechanism to access the file after its been printed.

In talking to Dan Walsh about the policy aspect of it we had talked
about polyinstantiating the output type, effectively user_lpr_t would
generate user_print_output_t.  While that would block secadm_lpr_t from
printing it would also stop secadm from reading someone else's output.

Your socket suggestion sounds interesting, but that would be adding
SELinux support for socket printers.  That might be interested to do at
some point, but for now I'm trying to wrap things up for the RHEL5
release.  As it is file printers were being added to automate evaluation
testing.  If there is no safe, secure way to facilitate file printers
they may not be supported in the evaluated configuration.

-matt

--
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 16:29 -0500, Matt Anderson wrote:
> Thats true, once there was output it would block other users from using
> that queue until it was removed.  This is intentional.

Ok.  Polyinstantiating the destination file would be nicer from a
functional point of view.

> The idea is to bring some sort of useful SELinux support to file
> printers.  In the case of file printers I've taken this to mean that the
> user who printed the job would be able to access the output directly.
> 
> Cups has no mechanism to access the file after its been printed.
> 
> In talking to Dan Walsh about the policy aspect of it we had talked
> about polyinstantiating the output type, effectively user_lpr_t would
> generate user_print_output_t.  While that would block secadm_lpr_t from
> printing it would also stop secadm from reading someone else's output.

In that case, security_compute_create() is what you want.  Passing in
the client's context as the first context, the context of the parent
directory in which the destination file will be created as the second
context, and SECCLASS_FILE for the security class, and returning the
context to put on the file.  That context would have the client's level,
and it would have either the parent directory's type (if no type
transition rule matches) or the type specified by a type transition rule
on the client's type and the parent directory type.

I assume you would limit the client to only read and write access to the
file, and not give it other permissions (e.g. create, unlink, rename,
etc), leaving such manipulations entirely to cupsd.

> Your socket suggestion sounds interesting, but that would be adding
> SELinux support for socket printers.  That might be interested to do at
> some point, but for now I'm trying to wrap things up for the RHEL5
> release.  As it is file printers were being added to automate evaluation
> testing.  If there is no safe, secure way to facilitate file printers
> they may not be supported in the evaluated configuration.

-- 
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: matchpathcon() for arbitrary subjects

[Matt Anderson]

Stephen Smalley wrote:
> On Tue, 2006-12-12 at 16:29 -0500, Matt Anderson wrote:
>> Thats true, once there was output it would block other users from using
>> that queue until it was removed.  This is intentional.
> 
> Ok.  Polyinstantiating the destination file would be nicer from a
> functional point of view.
> 
>> The idea is to bring some sort of useful SELinux support to file
>> printers.  In the case of file printers I've taken this to mean that the
>> user who printed the job would be able to access the output directly.
>>
>> Cups has no mechanism to access the file after its been printed.
>>
>> In talking to Dan Walsh about the policy aspect of it we had talked
>> about polyinstantiating the output type, effectively user_lpr_t would
>> generate user_print_output_t.  While that would block secadm_lpr_t from
>> printing it would also stop secadm from reading someone else's output.
> 
> In that case, security_compute_create() is what you want.  Passing in
> the client's context as the first context, the context of the parent
> directory in which the destination file will be created as the second
> context, and SECCLASS_FILE for the security class, and returning the
> context to put on the file.  That context would have the client's level,
> and it would have either the parent directory's type (if no type
> transition rule matches) or the type specified by a type transition rule
> on the client's type and the parent directory type.

Yes, thats exactly what I'd like to do.

> I assume you would limit the client to only read and write access to the
> file, and not give it other permissions (e.g. create, unlink, rename,
> etc), leaving such manipulations entirely to cupsd.

>From the perspective of $1_lpr_t I was intending to only allow write
permission, in order to validate that the user was able to print.  For
user_t it seemed to me that { read getattr relabelfrom link unlink
rename } was the correct set of permissions.  That way a user could copy
the output to another location.

I'm not sure how you would tell cupsd to remove the file.  Some sort of
admin role such as sysadm might also need the ability to unlink all of
these types in order to manage the queue.

-matt

--
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: matchpathcon() for arbitrary subjects

[Stephen Smalley]

On Tue, 2006-12-12 at 17:45 -0500, Matt Anderson wrote:
> Stephen Smalley wrote:
> > On Tue, 2006-12-12 at 16:29 -0500, Matt Anderson wrote:
> >> Thats true, once there was output it would block other users from using
> >> that queue until it was removed.  This is intentional.
> > 
> > Ok.  Polyinstantiating the destination file would be nicer from a
> > functional point of view.
> > 
> >> The idea is to bring some sort of useful SELinux support to file
> >> printers.  In the case of file printers I've taken this to mean that the
> >> user who printed the job would be able to access the output directly.
> >>
> >> Cups has no mechanism to access the file after its been printed.
> >>
> >> In talking to Dan Walsh about the policy aspect of it we had talked
> >> about polyinstantiating the output type, effectively user_lpr_t would
> >> generate user_print_output_t.  While that would block secadm_lpr_t from
> >> printing it would also stop secadm from reading someone else's output.
> > 
> > In that case, security_compute_create() is what you want.  Passing in
> > the client's context as the first context, the context of the parent
> > directory in which the destination file will be created as the second
> > context, and SECCLASS_FILE for the security class, and returning the
> > context to put on the file.  That context would have the client's level,
> > and it would have either the parent directory's type (if no type
> > transition rule matches) or the type specified by a type transition rule
> > on the client's type and the parent directory type.
> 
> Yes, thats exactly what I'd like to do.
> 
> > I assume you would limit the client to only read and write access to the
> > file, and not give it other permissions (e.g. create, unlink, rename,
> > etc), leaving such manipulations entirely to cupsd.
> 
> >From the perspective of $1_lpr_t I was intending to only allow write
> permission, in order to validate that the user was able to print.  For
> user_t it seemed to me that { read getattr relabelfrom link unlink
> rename } was the correct set of permissions.  That way a user could copy
> the output to another location.

read and getattr should be sufficient for copying the file to another
location, including copying it to a file of a different label (any label
to which the user can write).  unlink would be sufficient for removing
it.  relabelfrom isn't a good idea - user could relabel the printer file
in place, causing cupsd to get a denial.  link and rename seem prone to
abuse (e.g. user creates a link to the file in a different location,
tricking some other output stream to go into that printer file as well;
user renames the printer file to a different printer file's name, etc)
and unnecessary for the functionality you describe (just reading/copying
the output and removing the file when finished).

> I'm not sure how you would tell cupsd to remove the file.  Some sort of
> admin role such as sysadm might also need the ability to unlink all of
> these types in order to manage the queue.

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