Updated Release

Updated Release

[Howard Holm]

The SELinux web site <http://www.nsa.gov/selinux/> including the mail
list archive has been updated. The base kernel versions have been
updated to 2.5.74 and 2.4.21.  The SELinux API redesign with xattr
support has been completed for the version 2.5 based kernel.  The
SELinux daemon and utility patches have been ported to the new API. 
Support for the AT_SECURE auxv entry was added.  Changes were made to
bprm hook permission checking and nosuid operation.  A report, "Securing
the X Window System with SELinux" was added to documentation discussing
adding SELinux controls to the window system.  Finally, many contributed
patches to tools and policy have been merged and RPM spec files and
SRPMs are now provided.

-- 
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
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: Updated Release

[Christopher J. PeBenito]

I've been trying out the updated kernel patches, and I'm noticing a some
different behavior with the nfs lockd and rpciod.  With this release,
they're starting up in kernel_t:

 1057    344 system_u:system_r:portmap_t              [portmap]
 1135    346 system_u:system_r:rpcd_t                 [rpc.statd]
 1211    346 system_u:system_r:rpcd_t                 [nfsd]
 1212    346 system_u:system_r:rpcd_t                 [nfsd]
 1213    346 system_u:system_r:rpcd_t                 [nfsd]
 1214    346 system_u:system_r:rpcd_t                 [nfsd]
 1215      1 system_u:system_r:kernel_t               [lockd]
 1216      1 system_u:system_r:kernel_t                \_ [rpciod]
 1217    346 system_u:system_r:rpcd_t                 [nfsd]
 1218    346 system_u:system_r:rpcd_t                 [nfsd]
 1219    346 system_u:system_r:rpcd_t                 [nfsd]
 1220    346 system_u:system_r:rpcd_t                 [nfsd]
 1224    346 system_u:system_r:rpcd_t                 [rpc.mountd]

Its causing a couple denials:

avc:  denied  { recvfrom } for  pid=1216 comm=rpciod saddr=127.0.0.1
source=799 daddr=127.0.0.1 dest=111 netif=lo
scontext=system_u:system_r:portmap_t tcontext=system_u:system_r:kernel_t
tclass=udp_socket
avc:  denied  { recvfrom } for  pid=1215 comm=lockd saddr=127.0.0.1
source=800 daddr=127.0.0.1 dest=890 netif=lo
scontext=system_u:system_r:rpcd_t tcontext=system_u:system_r:kernel_t
tclass=udp_socket
avc:  denied  { recvfrom } for  pid=1135 exe=/sbin/rpc.statd
saddr=127.0.0.1 source=890 daddr=127.0.0.1 dest=800 netif=lo
scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:rpcd_t
tclass=udp_socket
avc:  denied  { write } for  pid=1215 comm=lockd lport=32770
scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:rpcd_t
tclass=udp_socket

However, I immediately restart with the previous release kerenel, w/o
relabelling or any other change, and they start up in rpcd_t:

 1109    342 system_u:system_r:portmap_t              [portmap]
 1182    344 system_u:system_r:rpcd_t                 [rpc.statd]
 1211    344 system_u:system_r:rpcd_t                 [nfsd]
 1212    344 system_u:system_r:rpcd_t                 [nfsd]
 1213    344 system_u:system_r:rpcd_t                 [nfsd]
 1214    344 system_u:system_r:rpcd_t                 [nfsd]
 1215    344 system_u:system_r:rpcd_t                 [nfsd]
 1216    344 system_u:system_r:rpcd_t                 [nfsd]
 1217    344 system_u:system_r:rpcd_t                 [nfsd]
 1218    344 system_u:system_r:rpcd_t                 [nfsd]
 1220    344 system_u:system_r:rpcd_t                 [lockd]
 1221    344 system_u:system_r:rpcd_t                  \_ [rpciod]
 1224    344 system_u:system_r:rpcd_t                 [rpc.mountd]

Is this intended?


On Fri, 2003-07-11 at 14:41, Howard Holm wrote:
> The SELinux web site <http://www.nsa.gov/selinux/> including the mail
> list archive has been updated. The base kernel versions have been
> updated to 2.5.74 and 2.4.21.
-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

--
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: Updated Release

[Stephen Smalley]

On Fri, 2003-07-11 at 19:31, Christopher J. PeBenito wrote:
> I've been trying out the updated kernel patches, and I'm noticing a some
> different behavior with the nfs lockd and rpciod.  With this release,
> they're starting up in kernel_t:
> Is this intended?

Yes, these are kernel threads, and they call reparent_to_init, so their
SID is changed to the kernel SID.  This isn't new to this release.

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

X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Bill Laut]

On Friday 11 July 2003 03:41 pm, Howard Holm wrote (in part):
>
> [...]
>
> A report, "Securing the X Window System with SELinux" was added to
> documentation discussing adding SELinux controls to the window system.
>

In addition to the other excellent items he mentioned, this line in Howard's 
announcement especially picqued my interest.  Recently I've been observing a 
cracker breaking into my honeypot by presumably compromising an email server 
I access in order to exploit a buffer overrun in KMail to then launch a 
buffer overrun in XFree86, so s/he can then insert spyware into the running 
kernel.  I qualify this statement because the cracker was leaving artifacts 
on my system but I didn't want to do anything that would let them know that I 
was onto their presence.

This leads me to the question:  While considerable work has been done to 
protect the system from server app compromises, what about protecting the 
system from server-based buffer overrun attacks on clients running under 
SELinux?

Also, is there a way to add types to each of the security services, so that 
compromised network clients can be blocked from becoming "security-aware?"  
For example, let's say I'm running KMail to retrieve my email from a 
latently-malicious email server.  It uses a buffer overrun to compromise my 
email client in order to then probe my security policy by attempting to 
invoke the various security system services and measure the results they 
return (whose summary results are then networked back out to a server 
somewhere on the 'Net).

For those network clients that have no reason to be security-aware, would it 
seem reasonable to audit and/or block their invocation of security system 
services as a possible probe by a compromised client?

Finally, it seems to me that filtching stored email would be a favorite target 
of industrial spies.  Accordingly, I was thinking that some sort of optional 
external abstraction (like, say, a PDA running an appropriate security app) 
might be useful for authorizing access to email files on a per-request basis.  
For example, if you wished to run your favorite email client you would first 
have to run an appropriate security app on your PDA, which then connects via 
the hotsync cradle to SELinux.  Then, as you access your email folders and/or 
Address Book, avc then asks the PDA app (as a trusted third party) whether or 
not to conditionally allow that access to occur.  In practice, the PDA would 
beep and then display a question concerning the access, which the user then 
taps the "allow" or "deny" buttons to resolve.  Should a malicious server 
then compromise the user's email client in order filtch his/her stored email, 
the user will immediately be alerted to this condition by the PDA beeping 
when no such email access should be occuring.  Appropriately, since the 
compromised email client will be patiently waiting for the fopen() service to 
complete, the security kernel would be able to preserve the client's stack 
for later analysis.

Would anyone care to comment on or critique these ideas?  Please pardon me in 
advance if some of the questions seemed obvious, as per my habit I was 
"thinking out loud" while typing them in.

Bill



--
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Tom]

On Wed, Jul 30, 2003 at 06:03:29PM -0400, Bill Laut wrote:
> This leads me to the question:  While considerable work has been done to 
> protect the system from server app compromises, what about protecting the 
> system from server-based buffer overrun attacks on clients running under 
> SELinux?

Some work has been done in this area. Russell wrote a policy for an irc
client as an example. It should be easy to write one for a mailer along
those lines.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Russell Coker]

On Thu, 31 Jul 2003 12:45, Tom wrote:
> On Wed, Jul 30, 2003 at 06:03:29PM -0400, Bill Laut wrote:
> > This leads me to the question:  While considerable work has been done to
> > protect the system from server app compromises, what about protecting the
> > system from server-based buffer overrun attacks on clients running under
> > SELinux?
>
> Some work has been done in this area. Russell wrote a policy for an irc
> client as an example. It should be easy to write one for a mailer along
> those lines.

Not that easy.

Using IRC without X access is no great hardship, while using a text based MUA 
loses significant functionality.  X is currently the main area that SE Linux 
does not address yet.

A mail client wants to access mail files under the user's home directory, this 
means that the files in question need a separate type as you don't want the 
mail client to access all the other files in the home directory.  This gives 
the usual issues of mv followed by file creation giving a different type and 
preventing things working in a way that novice users can't debug...

The mail client needs to be able to save files (easily managed) and to invoke 
the web browser and other programs (which may be more difficult).

Finally if using kmail then you have to deal with the kdeinit method of 
program launch...

-- 
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Tom]

On Fri, Aug 01, 2003 at 01:26:58AM +1000, Russell Coker wrote:
> Using IRC without X access is no great hardship, while using a text based MUA 
> loses significant functionality.  

Uh?
<img content="stupid look on face of an avid mutt user">

> X is currently the main area that SE Linux 
> does not address yet.

True. However, that is not a problem specific to a MUA.


> A mail client wants to access mail files under the user's home directory, this 
> means that the files in question need a separate type as you don't want the 
> mail client to access all the other files in the home directory.  This gives 
> the usual issues of mv followed by file creation giving a different type and 
> preventing things working in a way that novice users can't debug...

I'd do this the same way I did it with my subversion policy: Set up the
mail directory so that only the MUA (running in its own domain) can
access it. That way, the user simply can't mess up file labels.


> The mail client needs to be able to save files (easily managed) and to invoke 
> the web browser and other programs (which may be more difficult).

I've been wanting to create a "downloaded files" domain for netscape
anyways. Did I post about that already? In short, there'd be a
~/Downloads dir with a special type and some auto-trans rules so that
stuff you download and "try out" runs in an untrusted domain, etc.

Maybe we should just create a more general "untrusted files" domain?


> Finally if using kmail then you have to deal with the kdeinit method of 
> program launch...

I smell an SEKDE project on the horizon. From what I've seen, KDE is
way too integrated with itself to behave nicely with SE without changes 
in the KDE code itself.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Bill Laut]

On Thursday 31 July 2003 11:26 am, Russell Coker wrote:
> On Thu, 31 Jul 2003 12:45, Tom wrote:
> > On Wed, Jul 30, 2003 at 06:03:29PM -0400, Bill Laut wrote:
> > > This leads me to the question:  While considerable work has been done
> > > to protect the system from server app compromises, what about
> > > protecting the system from server-based buffer overrun attacks on
> > > clients running under SELinux?
> >
> > Some work has been done in this area. Russell wrote a policy for an irc
> > client as an example. It should be easy to write one for a mailer along
> > those lines.
>
> Not that easy.
>
> Using IRC without X access is no great hardship, while using a text based
> MUA loses significant functionality.  X is currently the main area that SE
> Linux does not address yet.
>

And, IMO, one of the greater dangers since it is/can be installed with 
privilege, so that a latent buffer overrun exploit there could allow an 
attacker unrestrained write access to the kernel itself.

>
> A mail client wants to access mail files under the user's home directory,
> this means that the files in question need a separate type as you don't
> want the mail client to access all the other files in the home directory. 
> This gives the usual issues of mv followed by file creation giving a
> different type and preventing things working in a way that novice users
> can't debug...
>

Or, perhaps, what is needed all along is a security-aware mail client that's 
been properly designed and tested against buffer overruns, so that it can 
specify the type for the files it creates/maintains while at least attempting 
to protect itself from being compromised by an exploit, along with existing 
files being properly relabeled.

>
> The mail client needs to be able to save files (easily managed) and to
> invoke the web browser and other programs (which may be more difficult).
>

Hmm.  This one needs to be thought about...

<tom@lemuria.org> wrote:
>>
>> Finally if using kmail then you have to deal with the kdeinit method of
>> program launch...
>>
>
> I smell an SEKDE project on the horizon.
>

I'm hearing the sound of Pandora's Box opening that I just opened... :-)

>
> From what I've seen, KDE is
> way too integrated with itself to behave nicely with SE without changes 
> in the KDE code itself.
>

I've been looking for an excuse to learn the internals of KDE, so it looks 
like I've found one.  Perhaps the first thing to do is tackle X before going 
after KDE?

Bill


--
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Russell Coker]

On Fri, 1 Aug 2003 02:26, Bill Laut wrote:
> > Using IRC without X access is no great hardship, while using a text based
> > MUA loses significant functionality.  X is currently the main area that
> > SE Linux does not address yet.
>
> And, IMO, one of the greater dangers since it is/can be installed with
> privilege, so that a latent buffer overrun exploit there could allow an
> attacker unrestrained write access to the kernel itself.

I think that you misunderstood my message.  I was referring to the fact that 
it is impossible to restrict an application which has X access from snooping 
the windows of other X programs or reading the keyboard buffer.

As for the access that the X server program gets, I run X with the FrameBuffer 
driver and it has no access to kernel memory and the only capabilities it has 
which are of note are sys_rawio and sys_admin.  I'm not sure why sys_admin is 
needed, and sys_rawio should not be needed for framebuffer (but the X server 
wants it anyway - probably a bug in the X server).

If we fix these issues then a compromise of the X server should not grant any 
access other than the ability to have total control over the screen and 
keyboard (which is still quite bad).

> > A mail client wants to access mail files under the user's home directory,
> > this means that the files in question need a separate type as you don't
> > want the mail client to access all the other files in the home directory.
> > This gives the usual issues of mv followed by file creation giving a
> > different type and preventing things working in a way that novice users
> > can't debug...
>
> Or, perhaps, what is needed all along is a security-aware mail client
> that's been properly designed and tested against buffer overruns, so that
> it can specify the type for the files it creates/maintains while at least
> attempting to protect itself from being compromised by an exploit, along
> with existing files being properly relabeled.

If we're going to do such things then the best first step would be to have an 
external program establish the POP/IMAP connection and then pass the file 
handle back to the main MUA.  Then the MUA would not have the passwords.  
Also something similar needs to be done for GPG.  Currently MUA's get the 
POP/IMAP passwords and the GPG pass-phrase in normal operation...

> > From what I've seen, KDE is
> > way too integrated with itself to behave nicely with SE without changes
> > in the KDE code itself.
>
> I've been looking for an excuse to learn the internals of KDE, so it looks
> like I've found one.  Perhaps the first thing to do is tackle X before
> going after KDE?

KDE is a much easier thing to work on...

-- 
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: X-Windows and Client-side Buffer Overruns (was Re: Updated Release)

[Bill Laut]

On Thursday 31 July 2003 07:41 pm, Russell Coker wrote:
> On Fri, 1 Aug 2003 02:26, Bill Laut wrote:
>
> > [My discussion of X's potential kernel access deleted]
> 
> I think that you misunderstood my message.  I was referring to the fact
> that it is impossible to restrict an application which has X access from
> snooping the windows of other X programs or reading the keyboard buffer.
>

Or, in the case of remotely-executing clients, a simple packet sniffer 
somewhere on the network.

I see your point now.  I'll discuss what I think may be a solution below.

>
> As for the access that the X server program gets, I run X with the
> FrameBuffer driver and it has no access to kernel memory and the only
> capabilities it has which are of note are sys_rawio and sys_admin.  I'm not
> sure why sys_admin is needed, and sys_rawio should not be needed for
> framebuffer (but the X server wants it anyway - probably a bug in the X
> server).
>

*light bulb suddenly turns on*   Hmm.....

>
> If we fix these issues then a compromise of the X server should not grant
> any access other than the ability to have total control over the screen and
> keyboard (which is still quite bad).
>

Here's my hypothetical solution to the window/keyboard snooping issue.  As a 
disclaimer, it's been awhile since I seriously hacked inside of X and it 
wasn't within Linux, so what I'm about to propose may be obsolete and/or 
irrelevant.  If so, please correct me.

Also, as a second disclaimer, up until now I've only had about two weeks to 
devote to learning SELinux.  I'm still digesting the syntax and capabilities 
of the various policy elements, let alone trying to write my first 
security-aware test application.  Therefore, if I make any assumptions about 
SELinux that are false, please point them out to me as I get myself up to 
speed.

As I remember it, X resembles something like this:

   [client and/or toolkit] <--> [xlib] <--> [transport] <--> [X server]

Of particular interest is the Transport layer, as it implements the Event and 
Request Queues for X.  Among others, it -can- expand to:

   [client-side Transport] <--> [TCP stream] <--> [server-side Transport]

On some implementations, such as under OpenVMS, this "functional layering" is 
strictly enforced such that multiple Transports are allowed to accomodate X 
sessions over nearly any networking protocol (ie, TCP/IP, DECnet, LAT, etc.), 
as well as having a "local" Transport optimized for clients that are running 
on the same box as the server.  As I understand it, however, in the 
Linux/Unix world allegedly there are some ugly hacks which violate this clean 
separation of layers/functions.

All of that notwithstanding, it would seem to me that X could be made at least 
partially security-aware where the server interfaces with its transport 
layer(s), because that would be the logical place to insert a "gatehouse" 
that not only inspects all incoming X protocol requests from the clients but 
can also distinguish between local and remote clients.

For local clients, the gatehouse could trivially determine the request's 
originating PID and then invoke the appropriate security service to inquire 
if that process' domain is authorized to issue those requests.

For remote clients, the gatehouse could pass along whatever relevant data it 
can collect (IP address, source socket #, etc.).  In the case of labelled 
networking, I'm guessing the gatehouse would have to extend into the 
Transport as well to retrieve that information?

Does this approach sound rational?  Unless I'm overlooking something, it 
should be possible to make X rather fine-grained.

>
> >
> > Or, perhaps, what is needed all along is a security-aware mail client
> > that's been properly designed and tested against buffer overruns, [...]
>
> If we're going to do such things then the best first step would be to have
> an external program establish the POP/IMAP connection and then pass the
> file handle back to the main MUA.  Then the MUA would not have the
> passwords.
>

To express it a different way, what you are proposing is something akin to 
running Sendmail and Qpopper on some a personal web/email server, but without 
the overkill those two apps represent because we would be "shrinking" them 
down to "personal-sized" proxy versions that can run on the same machine as 
the MUA.  This would also "re-direct" any buffer overflow exploits away from 
the MUA and onto the sendmail/qpopper pairing who could be hardened against 
such, while simultaneously extending the effort to the maximum number of MUAs 
available.  Correct?

>
> Also something similar needs to be done for GPG.  Currently
> MUA's get the POP/IMAP passwords and the GPG pass-phrase in normal
> operation...
>

That wouldn't be too hard to do.  In fact, it's something I've been toying 
with since late 2001.  I suggest the idea of using an SELinux-powered PDA for 
that purpose (such as a Sharp Zarus) in which the keyrings and all-important 
asymmetric crypto functions are off-loaded from the PC and moved to the PDA, 
and which the PC and PDA then communicate using an encrypted path through its 
Hotsync cradle.

Furthermore, this functionality could be extended into PAM so that the PDA 
could be used to authenticate the user's access to the PC.  Additionally, to 
appeal to larger organizations we could further leverage the PDA as the 
user's authenticator to the corporate firewall for determining what traffic, 
if any, is allowed access to the outside world, and to any servers for 
determining what access the user is authorized to have.

This may be something to keep in mind as labelled networking evolves beyond 
the experimental stage.

In summary, what I'm seeing is the potential for SELinux to quickly evolve 
into THE premiere security paradigm for Linux.

Obviously, the PDA now becomes the single point of failure in this security 
paradigm.  Accordingly, the only problem remaining is coming up with some 
form of encryption to protect its keyrings, etc. that is more secure than 
that "civilian-grade" AES.

Now, if Stephen knows anyone "down the hall" who could offer us some friendly 
suggestions and/or critique some potential ciphers for us...  ;-)

(Sorry about that, Stephen.  It's Friday and I couldn't resist that obvious 
plumb.)

>
> > > From what I've seen, KDE is
> > > way too integrated with itself to behave nicely with SE without changes
> > > in the KDE code itself.
> >
> > I've been looking for an excuse to learn the internals of KDE, so it
> > looks like I've found one.  Perhaps the first thing to do is tackle X
> > before going after KDE?
>
> KDE is a much easier thing to work on...
>

Interesting.  I had the impression that it's the other way around.

Well, let me finish coming up to speed on SELinux and then I'll tackle the X 
server mods.  Please advise on the design review procedure used by the team 
so that I can be in compliance.

For now, I'm tentatively planning to use the current XFree86 kit (v4.3.0) as 
my base, with the objective of producing xdelta patches to the tgz files that 
interested parties can download and apply to the official XFree86 distro.

Does this sound like a game plan to everyone?

Bill



--
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: X-Windows and Client-side Buffer Overruns

[Florian Weimer]

Bill Laut <wlsel@verizon.net> writes:

>> Also something similar needs to be done for GPG.  Currently
>> MUA's get the POP/IMAP passwords and the GPG pass-phrase in normal
>> operation...
>>
>
> That wouldn't be too hard to do.  In fact, it's something I've been toying 
> with since late 2001.  I suggest the idea of using an SELinux-powered PDA for 
> that purpose (such as a Sharp Zarus) in which the keyrings and all-important 
> asymmetric crypto functions are off-loaded from the PC and moved to the PDA, 
> and which the PC and PDA then communicate using an encrypted path through its 
> Hotsync cradle.

PDAs as heavy-weight smartcards?  Why not.

Smartcard support for GnuPG will arrive eventually, and all critical
passphrase/crypto stuff will be moved to gpg-agent, a separate
process.  (Most of this work is already done for GnuPG/X.509, I
suppose.)

--
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: X-Windows and Client-side Buffer Overruns

[Florian Weimer]

Russell Coker <russell@coker.com.au> writes:

> I think that you misunderstood my message.  I was referring to the
> fact that it is impossible to restrict an application which has X
> access from snooping the windows of other X programs or reading the
> keyboard buffer.

There are some X Security Extensions which restrict access to the root
window, windows of other client connections, and potentially dangerous
interfaces.  But I have never seen them in action, and these
restrictions are just an afterthought (added around 1996).

--
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: Updated Release

[Bill Laut]

On Friday 11 July 2003 03:41 pm, Howard Holm wrote:
>
> [...]
>
> A report, "Securing the X Window System with SELinux" was added to
> documentation discussing adding SELinux controls to the window system.
>

Where is this report located?  I've searched through both the 2.4 and 2.5 kits 
but cannot seem to locate it.

Bill


--
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: Updated Release

[Stephen Smalley]

On Wed, 2003-07-30 at 22:56, Bill Laut wrote:
> On Friday 11 July 2003 03:41 pm, Howard Holm wrote:
> >
> > [...]
> >
> > A report, "Securing the X Window System with SELinux" was added to
> > documentation discussing adding SELinux controls to the window system.
> >
> 
> Where is this report located?  I've searched through both the 2.4 and 2.5 kits 
> but cannot seem to locate it.

http://www.nsa.gov/selinux/x11-abs.html contains links to PDF and
PostScript versions of the document.  That page is linked into the
Documentation page (http://www.nsa.gov/selinux/docs.html), as well as
being directly linked by the What's New page
(http://www.nsa.gov/selinux/news.html).

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