identity

identity

[Russell Coker]

One of the benefits of the SE Linux identity is that it tracks the originating 
user through all operations that they perform.

With the user_u identity the utility of the identity for logging user 
activities is reduced.

Some people are talking about ways of tracking the source IP address for a ssh 
connection or other information on the login through user sessions in a 
similar manner.

It seems to me that we would gain a benefit if we had two parts to the 
identity string, the user-name that is compiled into the policy (and checked 
in the constraints file etc), and an arbitary string set by the login program 
or other equally privileged processes to be used for logging.

The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate that 
I logged in from IP address 10.0.0.1.

Steve, what do you think?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: identity

[Joseph Pingenot]

>From Russell Coker on Monday, 23 February, 2004:
>One of the benefits of the SE Linux identity is that it tracks the originating 
>user through all operations that they perform.
>With the user_u identity the utility of the identity for logging user 
>activities is reduced.
>Some people are talking about ways of tracking the source IP address for a ssh 
>connection or other information on the login through user sessions in a 
>similar manner.
>It seems to me that we would gain a benefit if we had two parts to the 
>identity string, the user-name that is compiled into the policy (and checked 
>in the constraints file etc), and an arbitary string set by the login program 
>or other equally privileged processes to be used for logging.
>The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate that 
>I logged in from IP address 10.0.0.1.
>Steve, what do you think?

Sorry.  Not Steve here.  :)

Sounds like a good idea.  One question:
Could you also record a signature of the data?  This would help distinguish
       processes who aren't supposed to be letting users on the system
       (since they'd not have a valid signature).  That'd potentially
       be able to plug a standard usage of rooted systems: leave open a
       port to the outside world to log in from.

-Joseph

-- 
Joseph===============================================trelane@digitasaru.net
      Graduate Student in Physics, Freelance Free Software Developer

--
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: identity

[Russell Coker]

On Mon, 23 Feb 2004 17:02, Joseph Pingenot <trelane@digitasaru.net> wrote:
> Sounds like a good idea.  One question:
> Could you also record a signature of the data?  This would help distinguish
>        processes who aren't supposed to be letting users on the system
>        (since they'd not have a valid signature).  That'd potentially
>        be able to plug a standard usage of rooted systems: leave open a
>        port to the outside world to log in from.

That wouldn't work.

If a regular user shell process running as user_u:user_r:user_t can access the 
network then it can also launch other shells.  There is no way of stopping 
this.

How do you distinguish a copy of bash launched as a shell for an interactive 
session from an interpreter for a shell script?

How do you distinguish programs such as "script" from a wrapper for a UDP 
based terminal system?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



--
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: identity

[Joseph Pingenot]

>From Russell Coker on Monday, 23 February, 2004:
>On Mon, 23 Feb 2004 17:02, Joseph Pingenot <trelane@digitasaru.net> wrote:
>> Sounds like a good idea.  One question:
>> Could you also record a signature of the data?  This would help distinguish
>>        processes who aren't supposed to be letting users on the system
>>        (since they'd not have a valid signature).  That'd potentially
>>        be able to plug a standard usage of rooted systems: leave open a
>>        port to the outside world to log in from.
>That wouldn't work.
>If a regular user shell process running as user_u:user_r:user_t can access the 
>network then it can also launch other shells.  There is no way of stopping 
>this.
>How do you distinguish a copy of bash launched as a shell for an interactive 
>session from an interpreter for a shell script?
>How do you distinguish programs such as "script" from a wrapper for a UDP 
>based terminal system?

Heh.  That's what I get for posting after just a moment's thought, right
  before I hit the hay.  :)
Excellent points.  I had originally been thinking that the info would
  be inherited by children (as would be logical), but it'd not actually
  prevent any such thing.  Dang.
Hmm.  Thinking about it again, maybe one could add a 'tainted' flag to
  a process that gets set when it listens to a socket?  Servers would
  be accompanied by a signature that verifies the integrity of the binary
  and are then not tainted on socket opening *if* they match?
Eh.  It seems like a good thing to eventually work towards.  :)

-Joseph

-- 
Joseph===============================================trelane@digitasaru.net
      Graduate Student in Physics, Freelance Free Software Developer

--
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: identity

[Joshua Brindle]

Joseph Pingenot wrote:

> From Russell Coker on Monday, 23 February, 2004:
> 
>>On Mon, 23 Feb 2004 17:02, Joseph Pingenot <trelane@digitasaru.net> wrote:
>>
>>>Sounds like a good idea.  One question:
>>>Could you also record a signature of the data?  This would help distinguish
>>>       processes who aren't supposed to be letting users on the system
>>>       (since they'd not have a valid signature).  That'd potentially
>>>       be able to plug a standard usage of rooted systems: leave open a
>>>       port to the outside world to log in from.
>>
>>That wouldn't work.
>>If a regular user shell process running as user_u:user_r:user_t can access the 
>>network then it can also launch other shells.  There is no way of stopping 
>>this.
>>How do you distinguish a copy of bash launched as a shell for an interactive 
>>session from an interpreter for a shell script?
>>How do you distinguish programs such as "script" from a wrapper for a UDP 
>>based terminal system?
> 
> 
> Heh.  That's what I get for posting after just a moment's thought, right
>   before I hit the hay.  :)
> Excellent points.  I had originally been thinking that the info would
>   be inherited by children (as would be logical), but it'd not actually
>   prevent any such thing.  Dang.
> Hmm.  Thinking about it again, maybe one could add a 'tainted' flag to
>   a process that gets set when it listens to a socket?  Servers would
>   be accompanied by a signature that verifies the integrity of the binary
>   and are then not tainted on socket opening *if* they match?
> Eh.  It seems like a good thing to eventually work towards.  :)
> 

Mine are inherited by children, i see what you are asking for but this 
seems far outside of the scope of selinux (not that mine are within 
scope per se. I don't like the idea of sticking this into userland 
becuase that requires modifying all login apps wheras mine is generic 
and works with anything that creates a socket. Another problem I see 
with this is, there is nothing that keeps a malicious userland app from 
reproducing that 'signature' so it's not incredibly useful.

I've looked at the selinux code for implementing something like this 
without reaching outside of selinux/lsm and I just don't see any way for 
it to be done since the sid is created in selinux and used to resolve to 
a string context (including identity). It would have been ideal to have 
an identity struct that arbitrary data could be added to but this isn't 
done in selinux.

Furthermore, I just did this patch because it's far easier to track down 
   the culprit of a rogue process if the ip information is available in 
addition to the context and UID.

--
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: identity

[Russell Coker]

On Tue, 24 Feb 2004 04:14, Joshua Brindle <jbrindle@snu.edu> wrote:
> I've looked at the selinux code for implementing something like this
> without reaching outside of selinux/lsm and I just don't see any way for
> it to be done since the sid is created in selinux and used to resolve to
> a string context (including identity). It would have been ideal to have
> an identity struct that arbitrary data could be added to but this isn't
> done in selinux.

The SID is initially created by a login program, which can easily be changed 
to add more data if the kernel is happy to deal with it.

The fact that it's not supported in SE Linux yet does not mean that it can't 
be added in the future.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: identity

[Stephen Smalley]

On Sun, 2004-02-22 at 23:35, Russell Coker wrote:
> One of the benefits of the SE Linux identity is that it tracks the originating 
> user through all operations that they perform.
> 
> With the user_u identity the utility of the identity for logging user 
> activities is reduced.
> 
> Some people are talking about ways of tracking the source IP address for a ssh 
> connection or other information on the login through user sessions in a 
> similar manner.
> 
> It seems to me that we would gain a benefit if we had two parts to the 
> identity string, the user-name that is compiled into the policy (and checked 
> in the constraints file etc), and an arbitary string set by the login program 
> or other equally privileged processes to be used for logging.
> 
> The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate that 
> I logged in from IP address 10.0.0.1.
> 
> Steve, what do you think?

This seems to overlap with Joshua Brindle's avc ipaddr patches, except
that his patches have the kernel track the IP addr and include it in the
AVC audit messages.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: identity

[Russell Coker]

On Tue, 24 Feb 2004 00:50, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > Steve, what do you think?
>
> This seems to overlap with Joshua Brindle's avc ipaddr patches, except
> that his patches have the kernel track the IP addr and include it in the
> AVC audit messages.

Yes.  My idea is (IMHO) a better way of achieving the same aims.

Having the kernel guess the IP address of the client will be difficult in the 
case of login servers that support NIS, LDAP, or Kerberos.  Also knowing more 
than just the IP address will often be useful.

If it's a plain text field that's set by the login process then an identd 
lookup could be performed, and any other data that seems relevant could be 
included.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: identity

[Russell Coker]

On Tue, 24 Feb 2004 14:08, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 24 Feb 2004 10:54:45 +1100, Russell Coker said:
> > If it's a plain text field that's set by the login process then an identd
> > lookup could be performed, and any other data that seems relevant could
> > be included.
>
> (Mostly for the archives, in case a newbie trawls up the thread...)
>
> If I'm running an identd server, it's not so you can make authentications
> decisions based on it.  It's so that if I have a multi-user system, and one
> of my users misbehaves, you can give me the string my machine sent you and
> then I'll know which of my users I need to beat the snot out of. ;)
>
> And of course, if my box is compromised or under the control of an
> adversary, the "authentication" provided by identd is "trust me"....

The same thing applies to IP addresses.  This is why I suggested just having 
it as essentially a comment.  It wouldn't be used for authentication, just 
for tracking the apparent cause of any problems.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: identity

[Stephen Smalley]

On Sun, 2004-02-22 at 23:35, Russell Coker wrote:
> One of the benefits of the SE Linux identity is that it tracks the originating 
> user through all operations that they perform.

Caveat:  This is no longer entirely true, as 'su' is now using
pam_selinux and transitions to other user identities.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: identity

[Joshua Brindle]

Stephen Smalley wrote:

> On Sun, 2004-02-22 at 23:35, Russell Coker wrote:
> 
>>One of the benefits of the SE Linux identity is that it tracks the originating 
>>user through all operations that they perform.
> 
> 
> Caveat:  This is no longer entirely true, as 'su' is now using
> pam_selinux and transitions to other user identities.
> 

Why was this decided, one of the main selling points of selinux was that 
the identity is always preserved, why back away from this concept?

 From talking to pebenito we aren't going to implement this at all in 
Gentoo, I'm wondering why others want to implement it.

Joshua Brindle

--
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: identity

[Stephen Smalley]

On Mon, 2004-02-23 at 14:32, Joshua Brindle wrote:
> Why was this decided, one of the main selling points of selinux was that 
> the identity is always preserved, why back away from this concept?
> 
>  From talking to pebenito we aren't going to implement this at all in 
> Gentoo, I'm wondering why others want to implement it.

To clarify, the SELinux user identity is still unaffected by setuid(2)
calls or setuid program execution.  Changing that behavior would be a
significant deviation.  Changing su(1) to support context transitions is
not; it has been suggested previously on the list, and my advice has
been to do it carefully, not to avoid doing it altogether.

In Fedora Core development, /etc/pam.d/su has been changed to use
pam_selinux, and the su policy in our tree has been extended to support
context transitions, so that a 'su whomever' will change to a context
appropriate for 'whomever'. /etc/security/default_contexts can be
configured to specify the desired default for su, and the 'multiple'
option to pam_selinux can be used to have su prompt the user for a
desired context when more than one option exists.  The pam_rootok module
has been changed to perform a SELinux permission check so that a uid 0
process cannot change to arbitrary contexts.

On the positive side, this means that:
a) You don't have to run newrole and su every time you want to
gain administrative privileges.
b) If you su to an ordinary user's account, you'll switch to a context
suitable for that user, so you won't accidentally end up executing their
.bashrc or similar under your own context.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: identity

[Russell Coker]

On Tue, 24 Feb 2004 01:28, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Sun, 2004-02-22 at 23:35, Russell Coker wrote:
> > One of the benefits of the SE Linux identity is that it tracks the
> > originating user through all operations that they perform.
>
> Caveat:  This is no longer entirely true, as 'su' is now using
> pam_selinux and transitions to other user identities.

Yes.  However I plan to make such use of su an optional feature so that people 
who desire the previous identity functionality where it can not be set by 
anything other than a login program can get it with minimal effort.

The Fedora default settings won't be used by everyone and I hope that when we 
release RHEL 4 we will have a good number of customers who want all the 
better security options enabled.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: identity

[James Morris]

On Mon, 23 Feb 2004, Russell Coker wrote:

> The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate that 
> I logged in from IP address 10.0.0.1.

How would the kernel know the IP address you're logged in from?  Would you 
also want to log the serial device if that's how the user logged in?


- James
-- 
James Morris
<jmorris@redhat.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: identity

[Stephen Smalley]

On Tue, 2004-02-24 at 09:47, James Morris wrote:
> On Mon, 23 Feb 2004, Russell Coker wrote:
> 
> > The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate that 
> > I logged in from IP address 10.0.0.1.
> 
> How would the kernel know the IP address you're logged in from?  Would you 
> also want to log the serial device if that's how the user logged in?

I tend to view this discussion as more appropriate for an auditing
framework rather than SELinux.  Likewise for preserving the original
user identity across all operations; that is typically an auditing
requirement rather than an access control requirement.  So I'd suggest
taking this up with people who are working on auditing frameworks.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: [selinux] Re: identity

[Magosányi Árpád]

Hi!

I tend to view "auditing framework" as a subset of "security framework",
and think that separating access control and audit is either unfeasible
or impossible, given that most of the stuff to be audited is access
control decision. Plus the access control logic can benefit from the
additional data which should be available for auditing purposes.
First it is a PITA that one have to dig out file name or IP address,
but you will soon realise that you can do access control decisions
based the data just mined out if you want.

On the other hand, there are some data (those which have to be used
for access control decisions) which should be dug out twice if you
want to separate auditing from access control.

And on the third hand:
Just tell me that FAU_GEN is not an aim of SELinux, and I will forget
the project forever.

2004-02-24, k keltezéssel Stephen Smalley ezt írta:

> > How would the kernel know the IP address you're logged in from?  Would you 
> > also want to log the serial device if that's how the user logged in?
> 
> I tend to view this discussion as more appropriate for an auditing
> framework rather than SELinux. 

-- 
GNU GPL: csak tiszta forrásból


--
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: [selinux] Re: identity

[Stephen Smalley]

On Tue, 2004-02-24 at 15:03, Magosányi Árpád wrote:
> I tend to view "auditing framework" as a subset of "security framework",
> and think that separating access control and audit is either unfeasible
> or impossible, given that most of the stuff to be audited is access
> control decision. Plus the access control logic can benefit from the
> additional data which should be available for auditing purposes.
> First it is a PITA that one have to dig out file name or IP address,
> but you will soon realise that you can do access control decisions
> based the data just mined out if you want.
> 
> On the other hand, there are some data (those which have to be used
> for access control decisions) which should be dug out twice if you
> want to separate auditing from access control.
> 
> And on the third hand:
> Just tell me that FAU_GEN is not an aim of SELinux, and I will forget
> the project forever.

An aim of SELinux itself?  No.  See the overview
(http://www.nsa.gov/selinux/), FAQ  
(http://www.nsa.gov/selinux/faq.cfm#I12), and prior postings to this
list on the topic of auditing, e.g.
http://marc.theaimsgroup.com/?l=selinux&m=97907408104978&w=2.  We agree
that auditing is important, and would encourage integration of SELinux
with an auditing framework (which can benefit both SELinux and the
auditing framework), but SELinux itself is not intended to meet auditing
requirements.  Note that LSM cannot meet auditing requirements, and the
right solution is not to bloat LSM into a universal hook framework but
instead to provide a separate framework for auditing.  The additional
state requested by Russell (including an immutable user identity for
audit records) belongs in an audit context, not the SELinux context.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: [selinux] Re: identity

[Joshua Brindle]

Stephen Smalley wrote:
> On Tue, 2004-02-24 at 15:03, Magosányi Árpád wrote:
> 
>>I tend to view "auditing framework" as a subset of "security framework",
>>and think that separating access control and audit is either unfeasible
>>or impossible, given that most of the stuff to be audited is access
>>control decision. Plus the access control logic can benefit from the
>>additional data which should be available for auditing purposes.
>>First it is a PITA that one have to dig out file name or IP address,
>>but you will soon realise that you can do access control decisions
>>based the data just mined out if you want.
>>
>>On the other hand, there are some data (those which have to be used
>>for access control decisions) which should be dug out twice if you
>>want to separate auditing from access control.
>>
>>And on the third hand:
>>Just tell me that FAU_GEN is not an aim of SELinux, and I will forget
>>the project forever.
> 
> 
> An aim of SELinux itself?  No.  See the overview
> (http://www.nsa.gov/selinux/), FAQ  
> (http://www.nsa.gov/selinux/faq.cfm#I12), and prior postings to this
> list on the topic of auditing, e.g.
> http://marc.theaimsgroup.com/?l=selinux&m=97907408104978&w=2.  We agree
> that auditing is important, and would encourage integration of SELinux
> with an auditing framework (which can benefit both SELinux and the
> auditing framework), but SELinux itself is not intended to meet auditing
> requirements.  Note that LSM cannot meet auditing requirements, and the
> right solution is not to bloat LSM into a universal hook framework but
> instead to provide a separate framework for auditing.  The additional
> state requested by Russell (including an immutable user identity for
> audit records) belongs in an audit context, not the SELinux context.
> 

On this note, are any of the selinux distro guys looking at integrating 
any specific auditing framework with selinux? We've looked at SAL a 
while back but it was very unsuitable at the time, and have plans to 
look at snare, are there others? If someone is alreay working on this 
let me know as I'd like to help.

Joshua Brindle

--
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: [selinux] Re: identity

[Rik Faith]

On Tue 24 Feb 2004 16:45:30 -0600,
   Joshua Brindle <jbrindle@snu.edu> wrote:
> On this note, are any of the selinux distro guys looking at integrating 
> any specific auditing framework with selinux?

I've been working on this and I'll post a patch under a new topic later
today (what I've implemented does not currently contain an identity
feature, but it could be added without much work).

> We've looked at SAL a while back but it was very unsuitable at the
> time, and have plans to look at snare, are there others?

I have looked at several system-call auditing frameworks but, in
general, they:
    1) did not integrate with SELinux (which often meant they did a
       tremendous amount of work that is subsumed by LSM), and
    2) they had broader goals (i.e., performance monitoring/tuning or
       debugging, for which they were willing to take a performance hit
       that is not reasonable to take for always-on security auditing).

> If someone is alreay working on this let me know as I'd like to help.

Great!


--
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: identity

[Russell Coker]

On Wed, 25 Feb 2004 01:47, James Morris <jmorris@redhat.com> wrote:
> On Mon, 23 Feb 2004, Russell Coker wrote:
> > The idea is to have something like rjc#10.0.0.1:user_r:user_t to indicate
> > that I logged in from IP address 10.0.0.1.
>
> How would the kernel know the IP address you're logged in from?

The login application would tell it.

> Would you
> also want to log the serial device if that's how the user logged in?

Sure.  That would be easy to do if the kernel supported arbitary text appended 
to the identity.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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