Possible bug with fd class?

Possible bug with fd class?

[Jason Johnson]

Hello all,

I am using SELinux on the latest debian.  It has a few access
violations here and there, but the one that concerns me most is:

kernel: [1298522.518701] type=1400 audit(1245126419.780:229): avc:
denied  { use } for  pid=29944 comm="syslog-ng" path="/dev/null"
dev=tmpfs ino=634 scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=fd


/dev/null is:

# semanage fcontext -l|grep null_device_t
/dev/null                                          character device
system_u:object_r:null_device_t:s0
/dev/full                                          character device
system_u:object_r:null_device_t:s0


I don't see a way with semanage to set anything about class "fd" and
sesearch didn't seem to turn anything up.  How could /dev/null fd be
in context logrotate_t?

I could just add an allow for this on a local module, but my concern
is: can a user program just set arbitrary fd's to it's own target
context as well?

I appreciate any insight you all can give.

Sincerely,
Jason

--
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: Possible bug with fd class?

[KaiGai Kohei]

Jason Johnson wrote:
> Hello all,
> 
> I am using SELinux on the latest debian.  It has a few access
> violations here and there, but the one that concerns me most is:
> 
> kernel: [1298522.518701] type=1400 audit(1245126419.780:229): avc:
> denied  { use } for  pid=29944 comm="syslog-ng" path="/dev/null"
> dev=tmpfs ino=634 scontext=system_u:system_r:syslogd_t:s0
> tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=fd
> 
> 
> /dev/null is:
> 
> # semanage fcontext -l|grep null_device_t
> /dev/null                                          character device
> system_u:object_r:null_device_t:s0
> /dev/full                                          character device
> system_u:object_r:null_device_t:s0
> 
> 
> I don't see a way with semanage to set anything about class "fd" and
> sesearch didn't seem to turn anything up.  How could /dev/null fd be
> in context logrotate_t?

The "fd" class represents a file descriptor object, not any filesystem
objects. For example, if you open the /tmp/aaa, this file belongs to
"file" class, but the file descriptor of the file belongs to "fd" class.

It seems to me the policy does not allow:

  logrotate_use_fds(syslogd_t)

> I could just add an allow for this on a local module, but my concern
> is: can a user program just set arbitrary fd's to it's own target
> context as well?

The fd class inherits the security context of the process which opened
itself.

> I appreciate any insight you all can give.
> 
> Sincerely,
> Jason
> 
> --
> 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.
> 
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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: Possible bug with fd class?

[Jason Johnson]

2009/6/16 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>
> The "fd" class represents a file descriptor object, not any filesystem
> objects. For example, if you open the /tmp/aaa, this file belongs to
> "file" class, but the file descriptor of the file belongs to "fd" class.

I figured it was something like that, but I didn't see any actions I
could take on fd's.

> It seems to me the policy does not allow:
>
>  logrotate_use_fds(syslogd_t)
>
> The fd class inherits the security context of the process which opened
> itself.

Ok, fair enough, but why is syslog-ng seeing /dev/null as a
logrotate_t target?  If logrotate opens /dev/null (as it probably
does) that shouldn't affect any other process that opens that same
device.  If it does that sounds like a potential security problem.


--
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: Possible bug with fd class?

[Stephen Smalley]

On Tue, 2009-06-16 at 19:31 +0200, Jason Johnson wrote:
> 2009/6/16 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> >
> > The "fd" class represents a file descriptor object, not any filesystem
> > objects. For example, if you open the /tmp/aaa, this file belongs to
> > "file" class, but the file descriptor of the file belongs to "fd" class.
> 
> I figured it was something like that, but I didn't see any actions I
> could take on fd's.
> 
> > It seems to me the policy does not allow:
> >
> >  logrotate_use_fds(syslogd_t)
> >
> > The fd class inherits the security context of the process which opened
> > itself.
> 
> Ok, fair enough, but why is syslog-ng seeing /dev/null as a
> logrotate_t target?  If logrotate opens /dev/null (as it probably
> does) that shouldn't affect any other process that opens that same
> device.  If it does that sounds like a potential security problem.

In this particular case it doesn't appear to be a problem, but often
programs unwittingly leak file descriptors when they exec a child
program.  Thus, this permission check has often been helpful in catching
such unintentional leaks, which can ultimately prove to be
security-relevant (leaking access to some resource that shouldn't be
accessible to the new program).

There are two checks applied:
- the fd use check, which controls whether a process can use a
descriptor originally opened by a process in a different security
context, and
- the file read/write/append checks, which control whether the process
can access the file in accordance with the open file flags.

If either set of checks fails, then the descriptor is closed and
replaced with a reference to the null device (to avoid application
misbehavior).

Naturally, if the passing of the descriptor is intentional and valid,
you can allow it in policy.

-- 
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: Possible bug with fd class?

[Jason Johnson]

On Tue, Jun 16, 2009 at 10:01 PM, Stephen Smalley<sds@tycho.nsa.gov> wrote:
>
> In this particular case it doesn't appear to be a problem, but often
> programs unwittingly leak file descriptors when they exec a child
> program.  Thus, this permission check has often been helpful in catching
> such unintentional leaks, which can ultimately prove to be
> security-relevant (leaking access to some resource that shouldn't be
> accessible to the new program).
>
> There are two checks applied:
> - the fd use check, which controls whether a process can use a
> descriptor originally opened by a process in a different security
> context, and
> - the file read/write/append checks, which control whether the process
> can access the file in accordance with the open file flags.
>
> If either set of checks fails, then the descriptor is closed and
> replaced with a reference to the null device (to avoid application
> misbehavior).
>
> Naturally, if the passing of the descriptor is intentional and valid,
> you can allow it in policy.

So are you saying that this /dev/null access by syslog-ng is actually
because some other access actually failed?

I don't see how this could be either:

# semanage fcontext -l|grep logrotate
/etc/cron\.(daily|weekly)/sysklogd                 regular file
system_u:object_r:logrotate_exec_t:s0
/var/lib/logrotate(/.*)?                           all files
system_u:object_r:logrotate_var_lib_t:s0
/usr/sbin/logrotate                                regular file
system_u:object_r:logrotate_exec_t:s0

Note that the odd sysklogd entry doesn't exist in either of those two
directories.


--
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: Possible bug with fd class?

[Stephen Smalley]

On Tue, 2009-06-16 at 23:13 +0200, Jason Johnson wrote:
> On Tue, Jun 16, 2009 at 10:01 PM, Stephen Smalley<sds@tycho.nsa.gov> wrote:
> >
> > In this particular case it doesn't appear to be a problem, but often
> > programs unwittingly leak file descriptors when they exec a child
> > program.  Thus, this permission check has often been helpful in catching
> > such unintentional leaks, which can ultimately prove to be
> > security-relevant (leaking access to some resource that shouldn't be
> > accessible to the new program).
> >
> > There are two checks applied:
> > - the fd use check, which controls whether a process can use a
> > descriptor originally opened by a process in a different security
> > context, and
> > - the file read/write/append checks, which control whether the process
> > can access the file in accordance with the open file flags.
> >
> > If either set of checks fails, then the descriptor is closed and
> > replaced with a reference to the null device (to avoid application
> > misbehavior).
> >
> > Naturally, if the passing of the descriptor is intentional and valid,
> > you can allow it in policy.
> 
> So are you saying that this /dev/null access by syslog-ng is actually
> because some other access actually failed?

No, that would show up as a separate AVC, and would
reference /selinux/null rather than /dev/null.

> I don't see how this could be either:
> 
> # semanage fcontext -l|grep logrotate
> /etc/cron\.(daily|weekly)/sysklogd                 regular file
> system_u:object_r:logrotate_exec_t:s0
> /var/lib/logrotate(/.*)?                           all files
> system_u:object_r:logrotate_var_lib_t:s0
> /usr/sbin/logrotate                                regular file
> system_u:object_r:logrotate_exec_t:s0
> 
> Note that the odd sysklogd entry doesn't exist in either of those two
> directories.

Some entries in file_contexts are for other distributions and may not
apply to your particular filesystem.  That's ok - it doesn't do any
harm.

-- 
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: Possible bug with fd class?

[Jason Johnson]

On Wed, Jun 17, 2009 at 2:26 PM, Stephen Smalley<sds@tycho.nsa.gov> wrote:
>> >
> No, that would show up as a separate AVC, and would
> reference /selinux/null rather than /dev/null.
>
> Some entries in file_contexts are for other distributions and may not
> apply to your particular filesystem.  That's ok - it doesn't do any
> harm.

Oh, I knew that entry wouldn't do anything.  I just meant that is the
closest connection I can see from syslog to logrotate.

So is this entry a bug:

kernel: [1298522.518701] type=1400 audit(1245126419.780:229): avc:
denied  { use } for  pid=29944 comm="syslog-ng" path="/dev/null"
dev=tmpfs ino=634 scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=fd

?

>From my limited understanding of how Selinux works I just don't see
how this is happening.


--
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: Possible bug with fd class?

[Stephen Smalley]

On Wed, 2009-06-17 at 20:28 +0200, Jason Johnson wrote:
> On Wed, Jun 17, 2009 at 2:26 PM, Stephen Smalley<sds@tycho.nsa.gov> wrote:
> >> >
> > No, that would show up as a separate AVC, and would
> > reference /selinux/null rather than /dev/null.
> >
> > Some entries in file_contexts are for other distributions and may not
> > apply to your particular filesystem.  That's ok - it doesn't do any
> > harm.
> 
> Oh, I knew that entry wouldn't do anything.  I just meant that is the
> closest connection I can see from syslog to logrotate.
> 
> So is this entry a bug:
> 
> kernel: [1298522.518701] type=1400 audit(1245126419.780:229): avc:
> denied  { use } for  pid=29944 comm="syslog-ng" path="/dev/null"
> dev=tmpfs ino=634 scontext=system_u:system_r:syslogd_t:s0
> tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=fd
> 
> ?

This just means that logrotate invoked syslog-ng while holding open a
descriptor to /dev/null.  Nothing more.

-- 
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: Possible bug with fd class?

[Stephen Smalley]

On Wed, 2009-06-17 at 15:13 -0400, Stephen Smalley wrote:
> On Wed, 2009-06-17 at 20:28 +0200, Jason Johnson wrote:
> > On Wed, Jun 17, 2009 at 2:26 PM, Stephen Smalley<sds@tycho.nsa.gov> wrote:
> > >> >
> > > No, that would show up as a separate AVC, and would
> > > reference /selinux/null rather than /dev/null.
> > >
> > > Some entries in file_contexts are for other distributions and may not
> > > apply to your particular filesystem.  That's ok - it doesn't do any
> > > harm.
> > 
> > Oh, I knew that entry wouldn't do anything.  I just meant that is the
> > closest connection I can see from syslog to logrotate.
> > 
> > So is this entry a bug:
> > 
> > kernel: [1298522.518701] type=1400 audit(1245126419.780:229): avc:
> > denied  { use } for  pid=29944 comm="syslog-ng" path="/dev/null"
> > dev=tmpfs ino=634 scontext=system_u:system_r:syslogd_t:s0
> > tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=fd
> > 
> > ?
> 
> This just means that logrotate invoked syslog-ng while holding open a
> descriptor to /dev/null.  Nothing more.

And I assume that's intentional, e.g. it is redirecting stdin, stdout,
stderr to /dev/null when invoking it.  So you can just allow it in your
policy.

-- 
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: Possible bug with fd class?

[Stephen Smalley]

On Thu, 2009-06-18 at 06:53 +0200, Jason Johnson wrote:
> On Wed, Jun 17, 2009 at 9:13 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
>         > On Wed, Jun 17, 2009 at 2:26 PM, Stephen
>         Smalley<sds@tycho.nsa.gov> wrote:
>         > >> >
>         
>         
>         This just means that logrotate invoked syslog-ng while holding
>         open a
>         descriptor to /dev/null.  Nothing more.
>         
>         
>         --
>         Stephen Smalley
>         National Security Agency
>         
>         
> 
> Ah!  I checked the logrotate configuration and I do see that daily it
> invokes:
> 
> /usr/sbin/invoke-rc.d syslog-ng reload >/dev/null
> 
> So that makes the /dev/null file descriptor that fd 2 (stdout) is
> opened to be logrotate_t?  Thanks very much for helping me understand
> how this is happening.
> 
> My one concern here is the solution.  What I would want to say from a
> high level is: "logrotate is allowed to run syslog-ng" or even more
> correct "logrotate is allowed to run the init.d syslog-ng script".
> What I actually have to say is: "syslog-ng is allowed to write to
> filedescriptors owned by logrotate".
> 
> I understand now why this situation happens, it just strikes me as an
> extremely low level interface.  What I have to do to allow logrotate
> to run syslog doesn't look very much like "let logrotate run
> syslog-ng's init.d script".  Further, since file descriptors are
> always inherited from the parent, wouldn't any program ran from any
> other program have a similar situation?  For example, if I took out
> the redirect to /dev/null then I would expect to get the same deny on
> whatever tty or file logrotate has connected to stdout.  Thoughts?
> 
> And thanks again everyone for your responses.

(restored cc line)

The policy already has rules to allow the transition from logrotate_t to
initrc_t when executing an init script, and from initrc_t to syslogd_t
when executing syslog-ng.  Further, the policy already has rules to
allow the initrc_t to inherit a descriptor from logrotate_t, and to
allow syslogd_t to inherit a descriptor from initrc_t.  What is missing
is a rule to allow syslogd_t to inherit a descriptor originally opened
by logrotate_t, as that is an indirect relationship.

If you really don't want to use the fd use controls, and only care about
the checks on the actual files, then you can disable the fd use controls
by enabling the allow_domain_fd_use boolean (at least in the Fedora
policy).

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