SELinux as a desktop / workstation?

SELinux as a desktop / workstation?

[Jan Petranek]

Hello there,

I assume, that most of you are using SELinux for server purposes. Is there
someone, who is using it for his everyday-desktop machine?

The reason for this question is:
- a server needs higher security levels than a client (normally, because
it is more exposed).
- a server can be limited to certain tasks (e.g. serving web-pages only),
whereas a workstation has to fit far more general needs (involving the use
of code belonging to the users), so far more complicated policies
would be necessary.

On the other hand, it would be useful, if simple workstations would offer
high (or at least a medium) level of security. For e.g., if the user
installs a program in his own userspace, he would want to limit the
program to certain capabilities. (You don't want your brand-new
napster-client to share your private keys with the napster-community ;)

Thank you,

JanP


--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[Will Dye]

Jan Petranek writes:

> I assume, that most of you are using SELinux for server purposes. 
> Is there someone, who is using it for his everyday-desktop machine?


A lot of Linux distros still turn on potentially-hazardous services 
by default, even on "workstation" installations.  I've read advice 
colums that strongly advise turning nearly all services off at all 
times, but personally I like having those options around.  I don't 
always know in advance when I might want to dial in from home to 
one of my work machines, for example.  Linux has not suffered as 
much as Windows from viruses & trojans, but it is not immune.  For 
these and other reasons, even Linux "workstation" installations may 
want ways to limit the amount of damage done by break-ins.

As long as the machine can handle a bit of a slowdown, I think it's 
a good idea to put something like SELinux on *every* system -- even 
my dinky old Toshiba 320CT laptop (266 MHz Pentium 1, 32 megs RAM).
There's a lot you can tweak if you need to cut back on the security 
processing overhead.  Desktop or server, I like my data intact.

Just one opinion,

--Will

 _____________________________________________________________________
 William Dye, Interim Chief Executive Cat-Herder, the Tweakdom Project
 Open-source tweaks to "Freedom", an Internet privacy software system.
 http://tweakdom.sourceforge.net   No relation Zero-Knowledge Systems.




--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[g.montgomery]

Jan Petranek wrote:
> 
> Hello there,
> 
Jan,
	I have been lurking on this list for a while,
as I am interested in bringing something like selinux
to the military applications environment in the
command and control field.  So, I do not speak with
authority, not having brought up SELinx, yet.

	But, I think I have seen the model which
appeals to my sensibilities, and other companies
are adopting the same model.  That is the ultra-secure
server, serving a set of ultra-thin clients.  That is,
the clients are like the Sun Sunray network appliance,
with no hard disk, no resident programs, and only the
RAM, and sufficient windowing software to get the
pixels on the screen.  Physical access of course,
is followed up by network access controlled by
Smart Card authentication/authorization (if I have
those terms right), and the session follows the
smart card.  Pull it out, and move to a different
network appliance, login, and your session has
magically moved there.

This provokes the question:

Is it better to put horsepower in both the server
and the client and try to keep them both secure
(especially in a multi-level security environment)
given that the constraints on the data and software
at the client end may be different than those
on the server end; or is it better to "put
all your eggs in one basket" so to speak, and
make the server the recipient of most all your
securification efforts?  (Of course, with the
constraint that the ultra-thin client is also
physically and electronically controlled for
access and authentication/authorization to the
required level.) 

Off the top of my head, considerations:
Pro:
	system administration at client end eliminated
	better control over centralized applications and databases	
Con:
	higher throughput required at server
	high bandwidth required between server and client
	
> I assume, that most of you are using SELinux for server purposes. Is there
> someone, who is using it for his everyday-desktop machine?
> 
> The reason for this question is:
> - a server needs higher security levels than a client (normally, because
> it is more exposed).
> - a server can be limited to certain tasks (e.g. serving web-pages only),
> whereas a workstation has to fit far more general needs (involving the use
> of code belonging to the users), so far more complicated policies
> would be necessary.
> 
> On the other hand, it would be useful, if simple workstations would offer
> high (or at least a medium) level of security. For e.g., if the user
> installs a program in his own userspace, he would want to limit the
> program to certain capabilities. (You don't want your brand-new
> napster-client to share your private keys with the napster-community ;)
> 
> Thank you,
> 
> JanP
> 
> --
> You have received this message because you are subscribed to the selinux 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.

Respectfully,

-- 
Gene Montgomery

--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[Bede McCall]

Offhand, I'd say you're describing the sort of thing prospective ASPs
have in mind as the ideal network, albeit not for security reasons.
I'm not as convinced as some folks that ASPs are a teriffic idea --
for now, at least.

The popularity of simple, stateless clients comes and goes.  For
example, we've seen IBM 3270s, X terminals, diskless workstations
(e.g., Sun's early systems running ND) and now SunRay, which bears a
family resemblance to X terminals and 3270s.  The history stretches
back to the glory days of Big Iron about 25 years ago, as punch cards
and batch systems were (finally) on their way out and decent multiuser
OS's were starting to show up (and many users thought the Lear ADM-3A
terminal was really hot stuff).

Securing simple, stateless clients is essentially a no-brainer,
letting you can focus all your energy on securing the server(s).  On
the down side, when someone finally breaks into a server, everyone's
instantly in deep trouble.

Of course, if someone gets into a stateful client (an easier job,
overall) they can gain access to anything that client had stored
locally, which might include keys, passwords, etc. allowing access to
one or more servers. It's also a lot harder to detect such intrusions,
mainly because users aren't as attuned to such things as sysadmins.
You can mitigate some of the server access-control problems (e.g., by
using "smart cards").

I think there's a good compromise design, though.

I think the facts argue in favor of distributed systems where *most*
of the executable applications reside on clients and *most* of the raw
data resides on servers.  A secure client with enough local stable
storage to hold at least a working set of raw data, a little non-global
information (e.g., local static configuration data) plus swap space
for its applications seems like a reasonable compromise.  Ob. selinux:
something like the SELinux-based kernel could be a very good choice of
OS on both client and server, given such a configuration.

While they will always have their place, simple-client schemes
generally haven't had a good survival rate, primarily because of the
non-security aspects of what you're doing.  For one thing, if the
server(s) for some group of clients crashes or becomes unavailable for
any reason, the users can't get any work done.  As Sun discovered
with ND, if you try to emulate stable storage on the client but locate
it physically on the ND server, you can congest the network very
quickly with swapping traffic (...and thereby make the application
server(s) unavailable).  Some folks will argue that there is easily
enough bandwidth in contemporary networks to overcome the congestion
problems we saw in early systems like ND, so they see ASPs and
"ultra-thin" clients as a very credible future.  I think that in the
case of hardware networks they're probably right, but the problem of
server robustness is as yet unsolved.


-- 
  Bede McCall   <bede@mitre.org>
  MITRE Corporation                        Tel: (781) 271-2839
  202 Burlington Road                      FAX: (781) 271-2423
  Bedford, Massachusetts  01730-1420

--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[g.montgomery]

Bede McCall wrote:
> 
> Offhand, I'd say you're describing the sort of thing prospective ASPs
> have in mind as the ideal network, albeit not for security reasons.
> I'm not as convinced as some folks that ASPs are a teriffic idea --
> for now, at least.
> 

I concur regarding ASPs - not sure I'd ever feel secure with
my stuff all being done "out there" in the great server
in the sky.  Of course, I still appear at the bank to do
my banking, and I even carry cash to buy stuff - old
fashioned, I guess.

> The popularity of simple, stateless clients comes and goes.  For
> example, we've seen IBM 3270s, X terminals, diskless workstations
> (e.g., Sun's early systems running ND) and now SunRay, which bears a
> family resemblance to X terminals and 3270s.  The history stretches
> back to the glory days of Big Iron about 25 years ago, as punch cards
> and batch systems were (finally) on their way out and decent multiuser
> OS's were starting to show up (and many users thought the Lear ADM-3A
> terminal was really hot stuff).
>

Yeah, been through all those devices, having started
opting for software back when Fortran was cool, and
programming in BAL/360 was for "real men".  A lot
has changed.
 
> Securing simple, stateless clients is essentially a no-brainer,
> letting you can focus all your energy on securing the server(s).  On
> the down side, when someone finally breaks into a server, everyone's
> instantly in deep trouble.
>

Yes, but if someone breaks into a critical server, you are in
trouble, no matter the system architecture. The idea is
to keep break-ins from happening.  The kinds of systems
I have dealt with have both physical and comsec security,
so break-ins of the "cracker" type are unlikely. (Has
anyone ever cracked SIPRNET, for example?)
 
> Of course, if someone gets into a stateful client (an easier job,
> overall) they can gain access to anything that client had stored
> locally, which might include keys, passwords, etc. allowing access to
> one or more servers. It's also a lot harder to detect such intrusions,
> mainly because users aren't as attuned to such things as sysadmins.
> You can mitigate some of the server access-control problems (e.g., by
> using "smart cards").
> 

Precisely.  

> I think there's a good compromise design, though.
> 
> I think the facts argue in favor of distributed systems where *most*
> of the executable applications reside on clients and *most* of the raw
> data resides on servers.  A secure client with enough local stable
> storage to hold at least a working set of raw data, a little non-global
> information (e.g., local static configuration data) plus swap space
> for its applications seems like a reasonable compromise.  Ob. selinux:
> something like the SELinux-based kernel could be a very good choice of
> OS on both client and server, given such a configuration.
> 
I like both your points.  First, I have seen a particular Sun
workstation (don't remember the model) which had a local
disk to hold enough of the operating system after booting
over the LAN, plus swap, data, and enough memory to
work in the problem space.  The advantage of this
arrangement was that there was light lan traffic, and
the local disk cached everything it needed to operate,
so it was quite fast - faster than x-terminals, etc. 
The admin problem was minimal.  I suppose there is still
an issue of volatile storage of (potentially) sensitive
or classified information, but that seems solvable. I
don't know how popular those were in general, but the
sysadmins in the lab I was working in at the time
liked them because the users didn't complain about
the slowness of the LAN, their displays were snappy,
and there was little sysadmin to take care of.  Everything
came from the server over the LAN, system was realtively
balanced.

Second, I have been wondering if selinux would provide
a good platform for both client and server, employing
MLS perhaps, and extending that across the system, with
a client node operating at a specific clearance level
as designated by the authentication/authorization
token (e.g., a programmed smart card).

> While they will always have their place, simple-client schemes
> generally haven't had a good survival rate, primarily because of the
> non-security aspects of what you're doing.  For one thing, if the
> server(s) for some group of clients crashes or becomes unavailable for
> any reason, the users can't get any work done.  As Sun discovered
> with ND, if you try to emulate stable storage on the client but locate
> it physically on the ND server, you can congest the network very
> quickly with swapping traffic (...and thereby make the application
> server(s) unavailable).  Some folks will argue that there is easily
> enough bandwidth in contemporary networks to overcome the congestion
> problems we saw in early systems like ND, so they see ASPs and
> "ultra-thin" clients as a very credible future.  I think that in the
> case of hardware networks they're probably right, but the problem of
> server robustness is as yet unsolved.
> 

True - server robustness is what one has to strive for.
To obtain availability of 5 nines, it would be
essential to have redundancy, "fail-safe" mechanisms,
etc.  While processor clustering, RAID, and other
techniques offer much, they are insufficient by themselves.
One needs a top-notch system design to approach the
"non-stop" operation demanded in mission critical
applications.  A system I recently worked on had
duplicate Sun servers, dual LAN arrangements, and in
general, a completely redundant set of nodes for
everything in the computing center.  I think the
(calculated) Availability was adequate for the
application, which was required to work with no
more than 15 minutes of down time in a year (IIRC).

Since the project was terminated for the
convenience ($$ shift) of the Government, we will never
know if the system would have met our projections,
but we felt we were on the right track.

BTW, that system had very thick dual-headed,
database hosting client nodes, so it doesn't
fit my mold of ultra-thin clients at all.  And the
thick client workstations were a bear to
develop software for and to administer in a 
DIICOE environment, which is one of the reasons
I have developed a liking for the thin clients.

When you are developing a system where most
of the interfaces must be developed from
scratch (that is, there is no well-oiled,
tried and proven message-passing protocol
which will support), then the interface between
the server and client is extremely important.
If you have a complex interface, with many
levels of statefulness, then it will take you
many years of testing to get the bugs out.
Not that it is easy if all the processing is done
on a server and "pixels" are shot out to an
ultra-thin client - it's just harder to do.
And, the other thing that happens when you
put that much functionality out in the
workstations is that you have to educate the
display developer guys/gals as to the 
functionality of your system, (the domain)
since they have part of the functionality 
out there in the client.  This increases the
cost of development, and results in a very
difficult project management problem. Better
if you can consider the client to be a
chunk of hardware, with NO software, if
possible.

So, if it sounds like I am letting the 
bureaucratic issues such as project management
get in the way of the system design, it 
just could be.  On the other hand, you could
look at it this way - If I can design a
system which requires 30% less in project
funding on a $300M project, and I only have
to spend say $200K x 10 (installations) extra as
an example, haven't I reduced the project
risk?  Shouldn't I consider that as an
important design criterion? I attribute
the extra cost to the increased server
power beyond the offset of the cheaper
client units. Round numbers - lots of
clients, so cutting the cost of them
by even a small amount significantly
reduces the system cost.

Sigh!  I guess there is no one system architecture
which answers all the mail.  Geez, have
I gotten off the selinux topic.  Probably
get flamed by someone.  Sorry!

Back on topic - has anyone suggested such
an archane thing as to use SELinux in
a beowulf cluster?

> --
>   Bede McCall   <bede@mitre.org>
>   MITRE Corporation                        Tel: (781) 271-2839
>   202 Burlington Road                      FAX: (781) 271-2423
>   Bedford, Massachusetts  01730-1420
> 
> --
> You have received this message because you are subscribed to the selinux 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.


Respectfully,
-- 
Gene Montgomery

--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[Will Dye]

Another possibility: give all the clients as much data and 
applications as you can fit in them, but keep it all encrypted 
and/or slightly incomplete.  Decryption keys and/or the missing 
pieces of critical information are available only from the 
servers.  

Extending the idea further, what if we had very smart clients, 
but processing (that is of interest to the server) may only run 
on a *virtual* machine.  The virtual machine mostly runs on the 
local client, but the integrity of the VM is cryptographically 
authenticated by the server before its output is approved.  In 
this scenario, the "dumb client" is a virtual machine, which 
runs on any of a variety of platforms -- even an ordinary PC 
somewhere on the Internet.  

The trick, of course is setting up a VM architecture that is 
both mathematically-sound and runs in a reasonable amount of 
time.  There are proofs that you can do generic computation 
in a distributed-yet-cryptographically-secure manner, but the 
problem is that you have to send a bunch of network packets 
just to get a single cycle on the VM.  Hmm.

Still, the idea has appeal.  When writing programs, we usually 
wind up making some kind of a VM model anyway -- even if it's 
only in the form of bogus assumptions by us coders.  :-)  

Besides, if you try to improve security by having only a 
restricted class of machines on your network, you eventually 
still have to set up a scheme to prove that the "dumb client" 
at a certain location isn't really Mallory's PC in disguise.
Thus, it seems like you'll have to make a VM model at some 
point or another anyway, and use that model to try to validate 
that the client hasn't been modified.  

In other words, you'll probably have to do the VM work anyway, 
including the part about having the server try to verify that 
the client is running according to specs.  If you have to go 
through all that, 'might as well make the client a VM, which 
you can then port to different platforms -- including a PC.  

The PC can run whatever junk the user wants, including Outlook 
viruses and who-knows-what.  Processing that is of interest to 
the server, however, has to run on a VM.  The PC can store as 
much as it likes locally, but nothing is decrypted until the 
server gives the OK, processing itself is kept scrambled, and 
the results have to be examined by the server in some form 
(hashes or whatever) before the key is sent that decrypts and 
presents the final answers.  

Just thinking out loud,


--Will

 _____________________________________________________________________
 William Dye, Interim Chief Executive Cat-Herder, the Tweakdom Project
 Open-source tweaks to "Freedom", an Internet privacy software system.
 http://tweakdom.sourceforge.net   No relation Zero-Knowledge Systems.




--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[Tom]

On Sat, May 12, 2001 at 04:08:42PM -0500, Will Dye wrote:
> Extending the idea further, what if we had very smart clients, 
> but processing (that is of interest to the server) may only run 
> on a *virtual* machine.  The virtual machine mostly runs on the 
> local client, but the integrity of the VM is cryptographically 
> authenticated by the server before its output is approved.  In 
> this scenario, the "dumb client" is a virtual machine, which 
> runs on any of a variety of platforms -- even an ordinary PC 
> somewhere on the Internet.  

a simple form of this is done in almost all multiplayer online games
(mostly to prevent cheating). the experience there is that it doesn't
work.



> Besides, if you try to improve security by having only a 
> restricted class of machines on your network, you eventually 
> still have to set up a scheme to prove that the "dumb client" 
> at a certain location isn't really Mallory's PC in disguise.
> Thus, it seems like you'll have to make a VM model at some 
> point or another anyway, and use that model to try to validate 
> that the client hasn't been modified.  

I have serious doubts that this will *ever* work. as long as the user
can theoretically access data that he shouldn't, he'll find a way to
actually do it.

the VM part has actually been used a while ago, and was even called
that - VMS. thin clients all over again, in VMS they just processed
user input and server output and ALL actual computations were done on
the server machine.


> The PC can run whatever junk the user wants, including Outlook 
> viruses and who-knows-what.  Processing that is of interest to 
> the server, however, has to run on a VM.  

and the VM will be hacked, reverse-engineered and pried wide open.
people do it in order to get better scores at GAMES. I'm fairly
pessimistic at their potential when it's about serious data instead.


a good general security model should - IMHO - work very much like a
good program: don't make assumptions and don't take shortcuts. you
can't assume the VM is what it should be once it left your hands. you
can't assume the line is clear or your crypto layer has not been broken
(the german u-boot command assumed that enigma was unbreakable - it may 
have been the deciding factor on the sea theatre).


-- 
-- http://web.lemuria.org
--

--
You have received this message because you are subscribed to the selinux 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 as a desktop / workstation?

[Jan Petranek]

On Fri, 11 May 2001, Bede McCall wrote:

> Date: Fri, 11 May 2001 20:51:10 -0400 (EDT)
> From: Bede McCall <bede@mitre.org>
> To: g.montgomery@gte.net
> Cc: jan.petranek@student.uni-tuebingen.de, selinux@tycho.nsa.gov
> Subject: Re: SELinux as a desktop / workstation?
>
> Offhand, I'd say you're describing the sort of thing prospective ASPs
> have in mind as the ideal network, albeit not for security reasons.
> I'm not as convinced as some folks that ASPs are a teriffic idea --
> for now, at least.

Actually, I was thinking of my own box only.

> The popularity of simple, stateless clients comes and goes.  For
> example, we've seen IBM 3270s, X terminals, diskless workstations
> (e.g., Sun's early systems running ND) and now SunRay, which bears a
> family resemblance to X terminals and 3270s.  The history stretches
> back to the glory days of Big Iron about 25 years ago, as punch cards
> and batch systems were (finally) on their way out and decent multiuser
> OS's were starting to show up (and many users thought the Lear ADM-3A
> terminal was really hot stuff).

Well, a thin-client/server approach is a good thing, but they will be used
only in certain environments. A typical scenario is a bank, where all the
clerks have a thin-client connecting to a transaction monitor - the latter
one is surrounded by thick walls and a squad of highly skilled
specialists, who keep the machine secure. The users can easily comply with
the security, as they have (related to software) no other choice. If a
clerk wants to browse the web, a simple look on a 3270-CUI will almost
certainly stop him. In the other case, the system administrator will just
smack him with the OS/390-manual.

But take a look at another scenario: A company, that develops software.
The users need
-acces to the internet. Doubly so, if they are
developing open source.
-mail to communicate with other programmers / companies
-their own private files, like private keys (You want to be sure, that the
patch your programmer just send in from wherever he is can be trusted).
-quite a lot of freedom to configure their desktop
-a compiler
-the possibility of running code from alien source, so they can evaluate
it. (this is granted by combining the compiler and acces to the web
already, I just wanted to point it out).

And in this scenario, a thin client is completely useless. Even, if you
put the whole applications on a server - like a remote desktop - the
software from alien source still has to run somewhere. Well, you might put
the sensitive things on a server (like the keys) and do everything else on
the local machine.

Third scenario: More and more people connect their box to the web. Thanks
to better pricing, they can stay almost permanently connected. What a
heaven for script-kiddies!

So, that would be a good place for an OS, that supports fine-grained
security policies: E.g. you could state, that the only way to acces
private keys is via the pgp-interface. Or, that if you surf the web, the
web browser will run in his own sandbox, without even knowing about your
newest software project. And the file-sharing utility would share exactly
the files you want to. Sounds like heaven, eh?

The reason I'm writing this is, that I'm a bit concerned about security
issues. Up to now, very little viruses have shaken the linux community,
but except for selinux and sandbox, there is no thing that prevents code
running in the user space from doing anything in the user space. If you
put a mail-client or web-browser for instance in the user space that
allows the execution of active code, root will stay protected, but the
user may loose a lot.

Thank you all for your comments on that,

JanP


--
You have received this message because you are subscribed to the selinux 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[2]: SELinux as a desktop / workstation?

[Maksim Otstavnov]

Hello Jan,

Friday, May 18, 2001, 6:22:43 PM, you wrote:

JP> The reason I'm writing this is, that I'm a bit concerned about security
JP> issues. Up to now, very little viruses have shaken the linux community,
JP> but except for selinux and sandbox, there is no thing that prevents code
JP> running in the user space from doing anything in the user space.

RSBAC (www.rsbac.org; see also ftp.altlinux.ru for Beta-version of "ALT
Linux Castle" distro).

JP> Thank you all for your comments on that,

Not at all. :)

Cheers,

-- 
-- Maksim Otstavnov <maksim@otstavnov.com> http://www.otstavnov.com
-- Computerra weekly,
--  contributing editor



--
You have received this message because you are subscribed to the selinux 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.