[PATCH] enable /proc/$$/loginuid

[Serge Hallyn]

Changelog:
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.

Is this ready for lkml?

thanks,
-serge

[David Woodhouse]

+#ifdef CONFIG
+ E(PROC_TID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
+#endif

Que?

[Stephen Smalley]

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like
newrole would like to have a more reliable user identity available than
the normal uid; we were having them extract the SELinux user identity
from the security context, but in Fedora, that is typically just user_u
due to the lack of integration of user management with policy.

[Serge E. Hallyn]

I was thinking of that as similar to AUDIT_LIST and AUDIT_GET. Clearly
they are different. I'll get rid of the capable call.

thanks,
-serge

Post by Stephen Smalley

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like
newrole would like to have a more reliable user identity available than
the normal uid; we were having them extract the SELinux user identity
from the security context, but in Fedora, that is typically just user_u
due to the lack of integration of user management with policy.
--
National Security Agency
--
Linux-audit mailing list
http://www.redhat.com/mailman/listinfo/linux-audit

[Serge E. Hallyn]

There is a bigger problem with the current loginuid assumptions. The
loginuid is stored on the audit_context. The audit_context is only
created when auditing has been enabled using auditctl, and an auditable
action has occurred.

Either we need to change the behavior to always create an audit_context
(with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
need to move loginuid directly into the task_struct.

-serge

Post by Stephen Smalley

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like
newrole would like to have a more reliable user identity available than
the normal uid; we were having them extract the SELinux user identity
from the security context, but in Fedora, that is typically just user_u
due to the lack of integration of user management with policy.
--
National Security Agency
--
Linux-audit mailing list
http://www.redhat.com/mailman/listinfo/linux-audit

[Inder Kumar]

Move loginuid(accountability information) to the task_struct. Why are
you using "loginuid" for accountability ?
What if two different users login using the same "loginuid" ?

Also, what is the advantage of using NETLINK sockets? It looks like
the information is passed to user-space for no-reason. The same
information will be passed back to the kernel by the syslog routines.
What is the point in doing such processing. Why are you not writing
records directly from the kernel to the audit file?

Regards
Surinder

Post by Serge E. Hallyn
There is a bigger problem with the current loginuid assumptions. The
loginuid is stored on the audit_context. The audit_context is only
created when auditing has been enabled using auditctl, and an auditable
action has occurred.
Either we need to change the behavior to always create an audit_context
(with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
need to move loginuid directly into the task_struct.
-serge

Post by Stephen Smalley

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like
newrole would like to have a more reliable user identity available than
the normal uid; we were having them extract the SELinux user identity
from the security context, but in Fedora, that is typically just user_u
due to the lack of integration of user management with policy.
--
National Security Agency
--
Linux-audit mailing list
http://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
http://www.redhat.com/mailman/listinfo/linux-audit

[Steve Grubb]

Post by Inder Kumar
Move loginuid(accountability information) to the task_struct. Why are
you using "loginuid" for accountability ?

We need to know who they logged in as. Some people login and then do 'su root'
and perform actions. We need to know who root logged in as.

Post by Inder Kumar
What if two different users login using the same "loginuid" ?

I suppose they are considered the same person.

Post by Inder Kumar
Also, what is the advantage of using NETLINK sockets?

Its a way of getting kernel information to userspace.

Post by Inder Kumar
It looks like the information is passed to user-space for no-reason.
The same information will be passed back to the kernel by the
syslog routines.

Actually, the audit subsystem decides where to send things - to special daemon
or syslog. The information is being passed to userspace for a reason. Some
installations require it has to be logged with great care. Syslog does not
meet the requirements for those users.

Post by Inder Kumar
What is the point in doing such processing. Why are you not writing
records directly from the kernel to the audit file?

That's what the userspace daemon does.

-Steve Grubb

[Timothy R. Chavez]

Also,

We may or someone else may want to provide advanced filtering
(anything more advanced then what is already provided) of audit
records before they reach an audit log. Better to do this filtering
in userspace via a daemon then in the kernel. We should keep the
in-kernel audit subsystem as small and efficient as possible.
Anything that can be delegated to userspace should be delegated to
userspace.

--
Timothy R. Chavez

[Leigh Purdie]

Post by Timothy R. Chavez
Also,
We may or someone else may want to provide advanced filtering
(anything more advanced then what is already provided) of audit
records before they reach an audit log. Better to do this filtering
in userspace via a daemon then in the kernel. We should keep the
in-kernel audit subsystem as small and efficient as possible.
Anything that can be delegated to userspace should be delegated to
userspace.

I think this is a pretty good idea - there are consequences though..

The number of events that need to be sent across to userspace for
processing may be significantly higher than what is finally delivered to
the log file, which could be considered by some to be a waste of
resources. Eg: If a user is only interested in files
in /data/secretstuff, then all the 'normal' file opens conducted by the
operating system (which may comprise 99% of events delivered to the
daemon), will be dropped by userspace pretty-much instantly - so much of
the effort the kernel goes through to write the info to userspace, might
be perceived to be wasted.

In snare, we generally see single-figure-percentage CPU resource
increases in normal operations using this exact approach - however, for
some operations (file-open auditing turned on, with many many small-file
opens occuring), this can increase to 30% or more. On the other hand,
much of that CPU work will have to be done somewhere - the kernel-

Post by Timothy R. Chavez
userspace comms are likely to occupy only a small percentage of that

work.

So, we have four alternative approaches here I think:
1) Dumb kernel, smart daemon. (this is the way Snare currently operates)
- Audit daemon turns on particular events (eg: file opens)
- Kernel sends ANY events that are file-open related to kernel.
- Daemon does all the filtering work

2) Semi-intelligent kernel, dumb daemon (Current implementation / LAUS).
- Audit daemon turns on particular events, plus some additional event
filters (eg: userid, success/failure)
- Kernel sends matching events to daemon, which writes the data out
appropriately.

3) Intelligent kernel / dumb daemon
- Audit daemon turns on particular events, plus some additional event
filters: userid, success/failure, wildcard-matched filenames?
- Kernel works out fully-qualified file paths, and matches against
wildcard match.

4) Semi-intelligent kernel, smart daemon
- Audit daemon turns on particular events, plus some additional event
filters (eg: userid, success/failure)
- Kernel works out fully-qualified file paths, but does not match
against wildcard filters.
- Kernel sends matching events to daemon, which writes the data out
appropriately.
- Daemon does MOST of the filtering work - particularly filenames.

Sounds like option 4 might be roughly what you're proposing?

L.

[Stephen Smalley]

Post by Serge E. Hallyn
There is a bigger problem with the current loginuid assumptions. The
loginuid is stored on the audit_context. The audit_context is only
created when auditing has been enabled using auditctl, and an auditable
action has occurred.
Either we need to change the behavior to always create an audit_context
(with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
need to move loginuid directly into the task_struct.

I'm not sure I follow. First, the current code seems to always set up
an audit context by default unless the task is explicitly marked
non-auditable. Second, even if an audit context does not exist, you can
easily check for a null audit context and just return (uid_t)-1 in that
case. The loginuid serves no purpose for non-auditable tasks, and it
seems wasteful to put it into the task struct.

[Steve Grubb]

Post by Stephen Smalley
The loginuid serves no purpose for non-auditable tasks, and it
seems wasteful to put it into the task struct.

I thought that people writing SE Linux policy wants this information available
for all tasks.

-Steve Grubb

[Stephen Smalley]

Post by Steve Grubb

Post by Stephen Smalley
The loginuid serves no purpose for non-auditable tasks, and it
seems wasteful to put it into the task struct.

I thought that people writing SE Linux policy wants this information available
for all tasks.

We'd like to have it available for programs like newrole, but that is
run from a user session and should thus already be auditable. Given
that an audit context is always set up unless the task is explicitly
marked non-auditable, and the only task likely to be marked
non-auditable is the audit daemon itself, I'm not sure why it matters.
Notice that at the point where an audit context is created for the task,
we don't have any criteria for determining whether the task should be
audited other than the pid and its parent task information. That is why
an audit context is almost always created, even if it isn't used in the
end.

[Stephen Smalley]

Post by Stephen Smalley
We'd like to have it available for programs like newrole, but that is
run from a user session and should thus already be auditable. Given
that an audit context is always set up unless the task is explicitly
marked non-auditable, and the only task likely to be marked
non-auditable is the audit daemon itself, I'm not sure why it matters.
Notice that at the point where an audit context is created for the task,
we don't have any criteria for determining whether the task should be
audited other than the pid and its parent task information. That is why
an audit context is almost always created, even if it isn't used in the
end.

BTW, I'm not fundamentally opposed to adding the loginuid to the task
struct, but I would tend to expect more resistance upstream to adding it
unless it can truly be justified. And I'm not sure that it is
justified...

[Serge Hallyn]

No, I guess I've been misreading the code. Now the only remaining
reason for keeping that patch is to use loginuid when audit_enabled=0.

So I take the patch back :)

I will re-diff the netlink-loginuid patch without the loginuid-into-
taskstruct.patch and send it back out.

thanks,
-serge

Post by Stephen Smalley

Post by Stephen Smalley
We'd like to have it available for programs like newrole, but that is
run from a user session and should thus already be auditable. Given
that an audit context is always set up unless the task is explicitly
marked non-auditable, and the only task likely to be marked
non-auditable is the audit daemon itself, I'm not sure why it matters.
Notice that at the point where an audit context is created for the task,
we don't have any criteria for determining whether the task should be
audited other than the pid and its parent task information. That is why
an audit context is almost always created, even if it isn't used in the
end.

BTW, I'm not fundamentally opposed to adding the loginuid to the task
struct, but I would tend to expect more resistance upstream to adding it
unless it can truly be justified. And I'm not sure that it is
justified...

[V***@vt.edu]

Post by Stephen Smalley
run from a user session and should thus already be auditable. Given
that an audit context is always set up unless the task is explicitly
marked non-auditable, and the only task likely to be marked
non-auditable is the audit daemon itself, I'm not sure why it matters.

Where do kernel-spawned threads like kjournald or the IRQ threads in Ingo's RT
patch end up?

[Serge Hallyn]

I'm assuming the loginuid needs to be set at the first login, and be
immutable. Let's say we have an audit rule for some inode ino. A task
accessing that inode won't have an audit_context until it touches that
inode. So there's no loginuid to associate with that action at that
time.

And by controlling when they access some auditable object, users might
be able to control the audited loginuid, rather than it being dictated
by the first uid logged in as, period.

Or am I misunderstanding the audit rules? If it's the case that for any
user UID for whom we will want to audit any action, there will be an
AUDIT_UID rule at audit_filter_rules(), then I guess this patch is
unnecessary (except for the SELinux use). It still means that any users
who log in before audit is enabled have no loginuid. That may be fine
from a CAPP perspective.

-serge

Post by Stephen Smalley

Post by Serge E. Hallyn
There is a bigger problem with the current loginuid assumptions. The
loginuid is stored on the audit_context. The audit_context is only
created when auditing has been enabled using auditctl, and an auditable
action has occurred.
Either we need to change the behavior to always create an audit_context
(with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
need to move loginuid directly into the task_struct.

I'm not sure I follow. First, the current code seems to always set up
an audit context by default unless the task is explicitly marked
non-auditable. Second, even if an audit context does not exist, you can
easily check for a null audit context and just return (uid_t)-1 in that
case. The loginuid serves no purpose for non-auditable tasks, and it
seems wasteful to put it into the task struct.

[Stephen Smalley]

Post by Serge Hallyn
I'm assuming the loginuid needs to be set at the first login, and be
immutable. Let's say we have an audit rule for some inode ino. A task
accessing that inode won't have an audit_context until it touches that
inode. So there's no loginuid to associate with that action at that
time.

I don't believe that this is how the current audit code works. An audit
context is initially set up for a task upon fork/clone via
copy_process-> audit_alloc. audit_alloc calls audit_filter_task to see
if the task has auditing completely disabled (which must be explicit;
the default is to build a context in the absence of any filters to
disable). Unless auditing is completely disabled for the task,
audit_alloc creates an audit context for the task, preserves the
loginuid from the parent (with my fix), and sets the syscall auditing
flag. Subsequently, audit-related information (e.g. paths, inodes,
devices) is captured during syscalls made by the task, and at syscall
exit, audit_syscall_exit calls audit_get_context, which now checks
filters to see if it should mark the context as auditable (and any
earlier calls to audit_log during the syscall e.g. by SELinux will have
already marked it auditable). If auditable, audit_syscall_exit will
then call audit_log_exit to perform the actual logging.

It has to work in this way for the reason you describe - we don't know
whether the task will trigger any auditable events a priori, so we must
set up an audit context and start capturing information unless the task
is explicitly marked as not requiring any auditing at all.

[Serge Hallyn]

That had been my original understanding, but I got some very odd results
over the weekend which led me to reread (and misread) the code. Namely,
I missed the exit default in audit_filter_task() being
AUDIT_BUILD_CONTEXT.

thanks,
-serge

Post by Stephen Smalley

Post by Serge Hallyn
I'm assuming the loginuid needs to be set at the first login, and be
immutable. Let's say we have an audit rule for some inode ino. A task
accessing that inode won't have an audit_context until it touches that
inode. So there's no loginuid to associate with that action at that
time.

I don't believe that this is how the current audit code works. An audit
context is initially set up for a task upon fork/clone via
copy_process-> audit_alloc. audit_alloc calls audit_filter_task to see
if the task has auditing completely disabled (which must be explicit;
the default is to build a context in the absence of any filters to
disable). Unless auditing is completely disabled for the task,
audit_alloc creates an audit context for the task, preserves the
loginuid from the parent (with my fix), and sets the syscall auditing
flag. Subsequently, audit-related information (e.g. paths, inodes,
devices) is captured during syscalls made by the task, and at syscall
exit, audit_syscall_exit calls audit_get_context, which now checks
filters to see if it should mark the context as auditable (and any
earlier calls to audit_log during the syscall e.g. by SELinux will have
already marked it auditable). If auditable, audit_syscall_exit will
then call audit_log_exit to perform the actual logging.
It has to work in this way for the reason you describe - we don't know
whether the task will trigger any auditable events a priori, so we must
set up an audit context and start capturing information unless the task
is explicitly marked as not requiring any auditing at all.

[Stephen Smalley]

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Do you really need the special case handling for the -1 loginuid?
And why include a newline?

[Steve Grubb]

Post by Stephen Smalley
Do you really need the special case handling for the -1 loginuid?

This would be easier to parse if it were numeric. This way strtoul won't
return 0. I guess the newline makes it fgets friendly. I don't mind that.

-Steve Grubb

[Serge E. Hallyn]

Post by Stephen Smalley
Do you really need the special case handling for the -1 loginuid?

I can manually print out "-1" if that would be nicer for processing,
but I really didn't want to print out ~0. Or am I really worrying
about nothing?

Post by Stephen Smalley
And why include a newline?

I can take that out... The /proc/$$/ files aren't consistent on how
to handle that.

-serge

[Stephen Smalley]

Post by Serge E. Hallyn
I can manually print out "-1" if that would be nicer for processing,
but I really didn't want to print out ~0. Or am I really worrying
about nothing?

I think the latter ;) If setreuid() and friends are already assuming
that -1 aka ~0 is never a legitimate uid, why can't you?

Post by Serge E. Hallyn
I can take that out... The /proc/$$/ files aren't consistent on how
to handle that.

It seems cleaner to omit it, IMHO.

[Stephen Smalley]

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Shouldn't you be using get_zeroed_page() on the read to avoid leaking
data to userspace? Or even do away with allocating a page at all there,
e.g. see sel_read_enforce in selinuxfs.c.

[Stephen Smalley]

Post by Stephen Smalley

Post by Serge Hallyn
1/14/2005: Added several checks for error values which were missing.
1/07/2005: First version.
Is this ready for lkml?

Shouldn't you be using get_zeroed_page() on the read to avoid leaking
data to userspace? Or even do away with allocating a page at all there,
e.g. see sel_read_enforce in selinuxfs.c.

Ah, never mind on the first point.

[Casey Schaufler]

Post by Stephen Smalley
Why require CAP_AUDIT_CONTROL to read the loginuid?

Since the loginuid identifies the individual who
will be held accountable for the action* it should
be hidden from untrusted (unprivileged) users to
prevent an evil minded program from taking actions
based on who will get the blame for them. This was
the guidance given us during the Trix B1 evaluation
of 1995.

----
* That's right, isn't it?


=====
Casey Schaufler
***@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Casey Schaufler]

... Better to
do this filtering
in userspace via a daemon then in the kernel. We
should keep the
in-kernel audit subsystem as small and efficient as
possible.
Anything that can be delegated to userspace should
be delegated to
userspace.

For this scheme to work the kernel has to
generate all possible records and pass them
on for filtering. This is much less efficient
than having the kernel filter records that
are known to be uninteresting. Filtering
must be done at a place where sufficient
information is available to make the choice,
and that means it must be done in the kernel
or that all possible filtering criteria must
be passed on.

There is no existing U2X audit implementation
that does all the filtering in user space.
It is not possible to reliably deliver the
total audit volume from a busy 4cpu system
through a single daemon. Attempting to do so
will validated the notion that auditing
slows the system. A kernel based filter scheme,
believe it or not, is much more efficient
just on the basis of data copying than any
userland scheme can hope to be.

I understand the pain involved with putting a
big chuck of code into the kernel. In this case
the alternative is not viable.


=====
Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

[Timothy R. Chavez]

On Mon, 17 Jan 2005 11:10:29 -0800 (PST), Casey Schaufler

Post by Casey Schaufler

... Better to
do this filtering
in userspace via a daemon then in the kernel. We
should keep the
in-kernel audit subsystem as small and efficient as
possible.
Anything that can be delegated to userspace should
be delegated to
userspace.

For this scheme to work the kernel has to
generate all possible records and pass them
on for filtering. This is much less efficient
than having the kernel filter records that
are known to be uninteresting. Filtering
must be done at a place where sufficient
information is available to make the choice,
and that means it must be done in the kernel
or that all possible filtering criteria must
be passed on.

Right, and such filtering already exists in the kernel and is mostly,
if not completely, sufficient to meet this goal. What I was getting
at is that there may be a desire to do additional filtering that goes
above and beyond what the kernel is capable of doing. Thus. this is
one reason why the audit daemon and not the kernel, should be used to
write out to the actual log file.

<snip>

Post by Casey Schaufler
=====
Casey Schaufler
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

[Leigh Purdie]

Post by Timothy R. Chavez
Right, and such filtering already exists in the kernel and is mostly,
if not completely, sufficient to meet this goal.
What I was getting
at is that there may be a desire to do additional filtering that goes
above and beyond what the kernel is capable of doing. Thus. this is
one reason why the audit daemon and not the kernel, should be used to
write out to the actual log file.

Note though, that the Solaris approach of passing a pipe file descriptor
to the kernel may still be a viable alternative if people REALLY want to
go down this path (wouldn't recommend it though, based on all the
troubles Sun have had with this approach).

L.

[Casey Schaufler]

Post by Timothy R. Chavez
Right, and such filtering already exists in the
kernel and is mostly,
if not completely, sufficient to meet this goal.
What I was getting
at is that there may be a desire to do additional
filtering that goes
above and beyond what the kernel is capable of
doing. Thus. this is
one reason why the audit daemon and not the kernel,
should be used to
write out to the actual log file.

Ah, yes. The initial version of SunOS audit
(back in the late 1980's) wrote directly from
the kernel to disk. The lesson was quickly
learned. Log file management, filtering,
notification, and a number of other functions
are much better done in user space code.


=====
Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

[Leigh Purdie]

Post by Casey Schaufler
Ah, yes. The initial version of SunOS audit
(back in the late 1980's) wrote directly from
the kernel to disk. The lesson was quickly
learned. Log file management, filtering,
notification, and a number of other functions
are much better done in user space code.

Believe it or not, it still does. :(
The solaris auditd functions as a 'management layer' for the kernel, but
effectively all it really does, is:
a) turn on/off particular events according to configurations
in /etc/security/audit_control, audit_event, and audit_class
b) open a file (eg: /var/audit/1234567.not-terminated.log), and pass the
file handle + a 'exit auditsvc if disk space falls below this threshold'
parameter to the auditsvc() system call.

However, they did add the capability to pass a 'pipe' file handle to
auditsvc() around 2.6, which meant that a third party app (like snare)
could add in some more advanced management/filtering etc.

L.

[Casey Schaufler]

Post by Leigh Purdie
Believe it or not, it still does. :(
The solaris auditd functions as a 'management layer'
for the kernel, but
a) turn on/off particular events according to
configurations
in /etc/security/audit_control, audit_event, and
audit_class
/var/audit/1234567.not-terminated.log), and pass the
file handle + a 'exit auditsvc if disk space falls
below this threshold'
parameter to the auditsvc() system call.

Yerg. Code I wrote before my forehead
meet my bald spot, still in use.


=====
Casey Schaufler
***@schaufler-ca.com




__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

[Casey Schaufler]

Post by Leigh Purdie
So, we have four alternative approaches here I
think: ...

A better way to look at it might be to have the
kernel deal with the "object policy" view and
have the daemon deal with the "user interface"
view. The kernel should filter on "accesses by
Leigh", and the daemon should filter files named
"*[Pp]urdie*". The kernel has to know that the
daemon wants to see all pathnames and pass them
along, and the daemon has to tell the kernel
what sort of records it needs to look at.

A dumb kernel will overwhelm the daemon, especially
if the daemon is smart. A kernel that tries to do
regular expressions is is trouble. No CAPP policy
is going to use wildcards, and "real" sysadmins
don't care about subject/object modeling.


=====
Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

[Casey Schaufler]

Post by Stephen Smalley
I'm not sure I follow. First, the current code
seems to always set up
an audit context by default unless the task is
explicitly marked
non-auditable.

Is it impossible for a task to change from
non-auditable to auditable without setting
the loginuid?

Is it possible for an auditable task to
perform an auditable action on the behalf
of a non-auditable task? An example here
might be a non-auditable GUI making a
request of the X11 server, or a non-auditable
cluster management daemon using a remote
service via xinetd. In either case the
auditable task needs the loginuid of the
non-auditable task in order to ensure that
auditing is done properly.

Post by Stephen Smalley
Second, even if an audit context
does not exist, you can
easily check for a null audit context and just
return (uid_t)-1 in that
case.

I'm sure an evaluation team would get a kick
out of finding that in the audit system
description.

Post by Stephen Smalley
The loginuid serves no purpose for
non-auditable tasks, and it
seems wasteful to put it into the task struct.

While the loginuid may not be directly useful
to a task that never generates audit records
it may be useful for other tasks that are doing
work on that task's behalf.

The audituid of xinetd is rarely interesting.
The audituid of a task that makes a request of
xinetd is usually interesting.


=====
Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

[Stephen Smalley]

Post by Casey Schaufler
Is it impossible for a task to change from
non-auditable to auditable without setting
the loginuid?

Setting the loginuid is independent of setting filtering rules on the
task, regardless of whether the loginuid is part of the task structure
or part of the audit context.

Post by Casey Schaufler
Is it possible for an auditable task to
perform an auditable action on the behalf
of a non-auditable task? An example here
might be a non-auditable GUI making a
request of the X11 server, or a non-auditable
cluster management daemon using a remote
service via xinetd. In either case the
auditable task needs the loginuid of the
non-auditable task in order to ensure that
auditing is done properly.

Even with a loginuid in the task structure, this would still require a
mechanism to pass the loginuid across network IPC and to verify it in
some manner. That is well beyond the scope of what we are discussing.

Post by Casey Schaufler
I'm sure an evaluation team would get a kick
out of finding that in the audit system
description.

If the task has no audit context, then it was explicitly marked as not
requiring any auditing. And by default, all tasks have audit contexts;
it requires explicit action to mark a task as non-auditable.

Post by Casey Schaufler
While the loginuid may not be directly useful
to a task that never generates audit records
it may be useful for other tasks that are doing
work on that task's behalf.
The audituid of xinetd is rarely interesting.
The audituid of a task that makes a request of
xinetd is usually interesting.

As above, this requires a mechanism to convey and verify loginuids
across network IPC. At that point, you might as well just use the user
identity from the SELinux security context, and leverage ongoing work to
integrate SELinux with IPSEC to implicitly label packets based on IPSEC
security associatio or other work to implement CIPSO-like options for
SELinux.

[Casey Schaufler]

Post by Stephen Smalley

Post by Casey Schaufler
Is it impossible for a task to change from
non-auditable to auditable without setting
the loginuid?

Setting the loginuid is independent of setting
filtering rules on the
task, regardless of whether the loginuid is part of
the task structure
or part of the audit context.

Okay, so if the task is non-auditable (and hence
has no loginuid because it has no audit context
to contain it) and is made auditable, where will
the audituid come from?

Post by Stephen Smalley
Even with a loginuid in the task structure, this
would still require a
mechanism to pass the loginuid across network IPC
and to verify it in
some manner. That is well beyond the scope of what
we are discussing.

While network services are the obvious example,
I have seen "helper programs" that have the same
issue. sudo is the general case of a helper program.
If sudo is exec'd by a process with an unset
loginuid, who is held accountable for the actions
it and its children perform?

And I thought that somewhere near the beginning
of the thread hucking the loginuid about was the
issue.

Post by Stephen Smalley

Post by Casey Schaufler
I'm sure an evaluation team would get a kick
out of finding that in the audit system
description.

If the task has no audit context, then it was
explicitly marked as not
requiring any auditing. And by default, all tasks
have audit contexts;
it requires explicit action to mark a task as
non-auditable.

Doesn't matter if it is possible to mark it
auditable some time in the future. You could
address this issue by making it impossible
to change a task from non-auditable to
auditable. Or, you can make sure that you
always have a loginuid around just in case
the task becomes auditable at some point in
the future. Either works. If you do it the
first way, you'll have to fix it later.

Post by Stephen Smalley
As above, this requires a mechanism to convey and
verify loginuids
across network IPC. At that point, you might as
well just use the user
identity from the SELinux security context, and
leverage ongoing work to
integrate SELinux with IPSEC to implicitly label
packets based on IPSEC
security associatio or other work to implement
CIPSO-like options for
SELinux.

You could well be right with regard to the
network issues, it's happened before.


=====
Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250