Re: Desktop apps interoperability

Re: Desktop apps interoperability

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> On Wed, 2005-03-30 at 07:05 -0800, Casey Schaufler
> wrote:
> ...
> > > Desktop apps will be restricted to only access
> the
> > > appropriate one.
> > > "Downloading" apps will be restricted to
> download to
> > > untrusted_content_t. 
> > 
> > Am I the only one wary of a slippery slope here?
> 
> What's the problem?

Unless I read your intent incorrectly (which
is possible) you're talking about requiring
the rearchitecting of the data storage schemes
for every user application on the planet to
accomodate the presence of DTE. And you're
talking about it as if it might actually happen.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Wed, 2005-03-30 at 07:52 -0800, Casey Schaufler wrote:
> --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > On Wed, 2005-03-30 at 07:05 -0800, Casey Schaufler
> > wrote:
> > ...
> > > > Desktop apps will be restricted to only access
> > the
> > > > appropriate one.
> > > > "Downloading" apps will be restricted to
> > download to
> > > > untrusted_content_t. 
> > > 
> > > Am I the only one wary of a slippery slope here?
> > 
> > What's the problem?
> 
> Unless I read your intent incorrectly (which
> is possible) you're talking about requiring
> the rearchitecting of the data storage schemes
> for every user application on the planet to
> accomodate the presence of DTE. And you're
> talking about it as if it might actually happen.

Do you have a better proposal for restricting desktop applications
to minimum privilege?

Nothing needs to be rearchitectured. The user just needs
to be made aware that this is where the documents belong, and
the app can't write all over the place like it would in a non-selinux
environment. Apps that still run in user_t would be unaffected until
their policy is changed.

Of course, I'm thinking in the future such folders would be prominently
displayed in Gnome with their own little icons, and their windows-style
names like "My Media" or whatever (which should not be the same 
as the actual dir. name), and those would go in the Places menu or
something, and sound juicer for example would know to write there by
default as opposed to somewhere else. 

I guess this discussion now becomes more GNOME-oriented, now that I
think about it. Maybe I should go bother the GNOME people to see what
they think about adding content-specific folders to /home that we can
label with different contexts..

... or am I missing something fundamental here? 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Tom]

On Wed, Mar 30, 2005 at 11:13:24AM -0500, Ivan Gyurdiev wrote:
> ... or am I missing something fundamental here? 

Yes.

_my_ directory structure will certainly look differently. Jack has yet
another one, Joe a third and Mary a fourth.


People who use Linux for their desktop usually enjoy one thing: That
they can sort things according to _their_ needs, not according to
whatever some "expert" in Redmond has prescribed.


Define the roles, but don't define the directories. If I want my
downloads in ~/Downloads/ and not in ~/content/downloads/ there is no
reason not to allow me that.


Plus, I still don't dig your "content" idea. First, it's a marketing
buzzword abstraction with zero meaning for regular folks. Two, are you
kidding me? How much "non-content" do you think I store in my $HOME to
give "content" it's own subdirectory?


-- 
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Wed, Mar 30, 2005 at 11:50:11PM +0200, Tom wrote:
> On Wed, Mar 30, 2005 at 11:13:24AM -0500, Ivan Gyurdiev wrote:
> > ... or am I missing something fundamental here? 
> 
> Yes.
> 
> _my_ directory structure will certainly look differently. Jack has yet
> another one, Joe a third and Mary a fourth.
 
 not when you recompile KDE [3.2.2 / 3.3] with the kdbfs
 patches, there ain't.

 kdbfs "flattens" the directory structures and forces applications,
 via patches to the file save and file open dialogs, to ONLY be able
 to save documents in certain subdirectories, ~/Documents, ~/Music ...
 etc.

 kdbfs then provides you with an "alternative" to the concept
 of a directory structure, with a much more comprehensive file
 open dialog box, which has exactly the same sort of search
 capabilities built-in that MAC OS/X has given people for
 several years now.

 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: Desktop apps interoperability

[Tom]

On Wed, Mar 30, 2005 at 11:12:46PM +0100, Luke Kenneth Casson Leighton wrote:
>  kdbfs "flattens" the directory structures and forces applications,
>  via patches to the file save and file open dialogs, to ONLY be able
>  to save documents in certain subdirectories, ~/Documents, ~/Music ...
>  etc.

There will be many people who reject that concept and our solution here
should cater to them as well. SELinux "but desktop apps are only
secured if you use KDE with a specific patch" is not something I would
find acceptable.


-- 
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Thu, Mar 31, 2005 at 10:37:36AM +0200, Tom wrote:
> On Wed, Mar 30, 2005 at 11:12:46PM +0100, Luke Kenneth Casson Leighton wrote:
> >  kdbfs "flattens" the directory structures and forces applications,
> >  via patches to the file save and file open dialogs, to ONLY be able
> >  to save documents in certain subdirectories, ~/Documents, ~/Music ...
> >  etc.
> 
> There will be many people who reject that concept 

 yep - i know.  i didn't say it was a "nice" solution.

 for "dummies" - the sorts of people who use MAC OS/X -
 directories are a massive confusional concept.

 think of the kinds of people who store 16,000 files in "My Documents"
 because they've never heard of creating folders.
 
 [and we won't talk about the person who spent 10 minutes each
 day paging down the same word document until they got to the
 end, okay? :) ]

 we are _privileged_ people who "understand" computers, graphical
 OSes, and such.

 it's vitally important to remember that there are people out there who:

 a) can't use a mouse

 b) can't phyisically or PSYCHOLOGICALLY see or locate a cursor
    (esp. the Mozilla Firefox and MS Word vertical bar ones)

 c) don't really understand the concept of folders being a thing
    with a border around it, let alone directories.

 so, whilst we all "love" to put documents where we "want", creating
 lovely structured directory hierarchies with symlinks to convenient
 places, the majority of users simply use what's put in front of them
 [and typically use or grok very little of even that].

 and Apple put the "finder" in front of people, on MAC-OS/X,
 and they sodding love it, because it finds EVERYTHING that's
 useful to them.

 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: Desktop apps interoperability

[Ivan Gyurdiev]

> People who use Linux for their desktop usually enjoy one thing: That
> they can sort things according to _their_ needs, not according to
> whatever some "expert" in Redmond has prescribed.

It's hard to think of a plan that confines desktop applications, if
people want to do whatever they'd like with their system, not caring
about file placement. I had the same opinion about a year ago when
SElinux started restricting what I do with my files outside ~/home - 
I had a folder called /data, and now that wouldn't be accessible 
the way I expected. I wasn't too happy about it, but since then I've 
accepted that it's necessary for me to change my expectations a bit.

The root user already can't do whatever he wanted to before - there's
an expected schema that he/she must follow in order for things to work -
expected placement of system files. This is just extending that
restriction to the /home folder.

If you have a better proposal...

> Define the roles, but don't define the directories. If I want my
> downloads in ~/Downloads/ and not in ~/content/downloads/ there is no
> reason not to allow me that.

Well, If you want to create ~/Downloads and label it with the proper
context manually, there wouldn't be anything to stop you, and that 
should work. However, I think a folder should already exists, which is
properly labeled, so a user wouldn't have to figure out how to do this
by themselves.

> Plus, I still don't dig your "content" idea. First, it's a marketing
> buzzword abstraction with zero meaning for regular folks. Two, are you
> kidding me? How much "non-content" do you think I store in my $HOME to
> give "content" it's own subdirectory?

You store .bashrc, .bash_profile, .xauth files, configuration files, 
secret gpg keyrings... Those are all things I wouldn't describe as
content. If it's hidden, then I wouldn't consider it content.
-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2005-03-31 at 08:51 -0800, Casey Schaufler
> wrote:
> > Existing MLS systems allow unprivileged
> > applications to run unmodified. In at least
> > one case that included an unmodified X server.
> > You have to do at least as well as the unix MLS
> > systems to be credible. You think that's a
> > low bar, so you shouldn't have any trouble,
> > right?
> 
> You can certainly allow applications to run
> unmodified on SELinux today.

This is critically important to the possibility
of widespread acceptance of the system.

> But there can be benefit from modifying applications
> to provide stronger
> isolation and true least privilege in the future.

To be sure. An application that is written with
understanding of the environment in which it runs
will always have the advantage over the one that
is not.
 
> And users do care
> about these "unprivileged" applications corrupting
> or leaking their
> data.

True enough. Nonetheless, the operating
system developer must have enough confidence
in the policies and mechanisms of the OS to
let the application developer do arbitrary
unprivileged things. Only a truely closed
system can control everything, which is why
the clear definition of system policies is
so important in an open or open source system.


Casey Schaufler
casey@schaufler-ca.com


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

--
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: Desktop apps interoperability

[Casey Schaufler]

--- Rogelio Serrano <rogelio.serrano@gmail.com> wrote:

> Unchangeable legacy apps should die.

Get on the phone to RMS! Get gnu cracking!

>  
> > But you don't want to just
> accept that status quo
> > for all applications for all time, which seemed to
> be Casey's attitude.

That's my stance on "untrusted" applications. 
If I don't trust it, I have to accept that it
might try anything. I also have to accept that
someone might want it to work. These are the
applications we need secure systems for.

> I think everybody agrees that aggressive
> refactorization of source
> code is a good thing.

Except when it works the way it is now?

> Therefore in an open source
> environment legacy
> apps dont exist.

Bah! (waves paw)


Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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: Desktop apps interoperability

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2005-03-31 at 08:05 -0800, Casey Schaufler
> wrote:
> > Look here, sonny, I've been doing MLS systems
> > since 1986 and the One Truth You Must Learn
> > is that applications can not be changed. No.
> > Don't even consider thinking in this direction.
> > This is wrong. Sometimes all that's available
> > is the binary. Sometimes they like the way it
> > works.
> 
> Ah, yes.  That's certainly the example we should be
> following...the
> example set by past trusted/MLS OSes.

Oooooh! Sarcasm!

Existing MLS systems allow unprivileged
applications to run unmodified. In at least
one case that included an unmodified X server.
You have to do at least as well as the unix MLS
systems to be credible. You think that's a
low bar, so you shouldn't have any trouble,
right?

> No thanks,
> we're trying to solve
> real problems here...

Ah, and the horse you rode in on.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Stephen Smalley]

On Thu, 2005-03-31 at 08:51 -0800, Casey Schaufler wrote:
> Existing MLS systems allow unprivileged
> applications to run unmodified. In at least
> one case that included an unmodified X server.
> You have to do at least as well as the unix MLS
> systems to be credible. You think that's a
> low bar, so you shouldn't have any trouble,
> right?

You can certainly allow applications to run unmodified on SELinux today.
But there can be benefit from modifying applications to provide stronger
isolation and true least privilege in the future.  And users do care
about these "unprivileged" applications corrupting or leaking their
data.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> On Wed, 2005-03-30 at 09:58 -0800, Casey Schaufler
> wrote:
> > --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > 
> > > Ok, some apps like gift don't ask where to save
> the
> > > content, 
> > > but that's the exception and not the rule. 
> > 
> > I challenge you to back up this claim.
> 
> I don't need to back up this claim, because:

Of course you don't need to back up the claim.

> 1) Apps that don't let you configure where to save
> your content are
> badly designed.

This may be true, but the quality of design
is not an issue.

> 2) They can be changed

Look here, sonny, I've been doing MLS systems
since 1986 and the One Truth You Must Learn
is that applications can not be changed. No.
Don't even consider thinking in this direction.
This is wrong. Sometimes all that's available
is the binary. Sometimes they like the way it
works.

> 3) If they're not changed, it doesn't matter,
> because what I'm proposing
> is backwards compatible. User_t will still have
> access to all content
> types, and can write stuff to /home as user_home_t.

But ...

> Apps will have to be
> specifically confined in order not to be able to
> write to user_home_t.
> If some app is a problem, it can be left to run at
> user_home_t for now.

... then what's your whole point? I mean,
why this whole line about structuring where
user data goes?

> 4) If apps store stuff in a hardcoded location, we
> can label that easily
> with the proper context, unless it's hardcoded to
> /home or some other
> shared place. 

You're right. 

> Anyway, I am starting to get a better idea as to how
> this might work - 
> see my response to Luke's message.

Will have a look. BTW, good work.
Don't let a dinosaur like me get in
your way of making things work right.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Stephen Smalley]

On Thu, 2005-03-31 at 08:05 -0800, Casey Schaufler wrote:
> Look here, sonny, I've been doing MLS systems
> since 1986 and the One Truth You Must Learn
> is that applications can not be changed. No.
> Don't even consider thinking in this direction.
> This is wrong. Sometimes all that's available
> is the binary. Sometimes they like the way it
> works.

Ah, yes.  That's certainly the example we should be following...the
example set by past trusted/MLS OSes.  No thanks, we're trying to solve
real problems here...

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Tom]

On Thu, Mar 31, 2005 at 11:08:07AM -0500, Stephen Smalley wrote:
> > Look here, sonny, I've been doing MLS systems
> > since 1986 and the One Truth You Must Learn
> > is that applications can not be changed. No.
> > Don't even consider thinking in this direction.
> > This is wrong. Sometimes all that's available
> > is the binary. Sometimes they like the way it
> > works.
> 
> Ah, yes.  That's certainly the example we should be following...the
> example set by past trusted/MLS OSes.  No thanks, we're trying to solve
> real problems here...

He does have a point, though - sometimes the application can not be
changed. It may be a legacy application and for all I care, those are
the ones most in need of a protective cage.



-- 
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: Desktop apps interoperability

[Stephen Smalley]

On Thu, 2005-03-31 at 23:13 +0200, Tom wrote:
> He does have a point, though - sometimes the application can not be
> changed. It may be a legacy application and for all I care, those are
> the ones most in need of a protective cage.

Sure, and at that point, you just confine it as best as you can while
still allowing whatever functionality you require.  SELinux supports
that need just fine.  But you don't want to just accept that status quo
for all applications for all time, which seemed to be Casey's attitude.
 
-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Rogelio Serrano]

On Apr 1, 2005 5:05 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2005-03-31 at 23:13 +0200, Tom wrote:
> > He does have a point, though - sometimes the application can not be
> > changed. It may be a legacy application and for all I care, those are
> > the ones most in need of a protective cage.
> 

Unchangeable legacy apps should die.
 
> Sure, and at that point, you just confine it as best as you can while
> still allowing whatever functionality you require.  SELinux supports
> that need just fine.  But you don't want to just accept that status quo
> for all applications for all time, which seemed to be Casey's attitude.
> 
[snipped...]

I think everybody agrees that aggressive refactorization of source
code is a good thing. Therefore in an open source environment legacy
apps dont exist.

-- 
Blood is thicker than water... and much tastier
                                           John Davidorff Pell

--
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: Desktop apps interoperability

[Tom]

On Fri, Apr 01, 2005 at 01:28:29PM +0800, Rogelio Serrano wrote:
> > > He does have a point, though - sometimes the application can not be
> > > changed. It may be a legacy application and for all I care, those are
> > > the ones most in need of a protective cage.
> 
> Unchangeable legacy apps should die.

Just like hunger and war, yes. The fact remains that they exist, and
you and I have to work with (and/or around) them.

Now, you _can_ do binary patching or even runtime binary patching, you
can overload system calls, you can do all sorts of dirty tricks to
change the behaviour of an "unchangeable" app. In most cases that's
non-trivial and it'll certainly mean you lose customer support.

SELinux is an excellent way to deal with these abominations and beat a
little sense into them. Were you on the list 2 years ago or so, when I
wrote policies for commercial Linux games? The audit log is an
interesting read, you wouldn't _believe_ what they try to access for no
obvious reason.



-- 
PGP/GPG key: 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: Desktop apps interoperability

[Ivan Gyurdiev]

> > 3) If they're not changed, it doesn't matter,
> > because what I'm proposing
> > is backwards compatible. User_t will still have
> > access to all content
> > types, and can write stuff to /home as user_home_t.
> 
> But ...
> 
> > Apps will have to be
> > specifically confined in order not to be able to
> > write to user_home_t.
> > If some app is a problem, it can be left to run at
> > user_home_t for now.
> 
> ... then what's your whole point? I mean,
> why this whole line about structuring where
> user data goes?

Because then certain applications can be constrained further than
they are constrained right now. They will be revoked privileges
to user_home_t, and you will have a more secure system, since exploits
of that app will not affect data in the user_home_t domain.

Specifically, the download folder is most important to implement, as
the target folder for any potentially hostile content.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:

> Ok, some apps like gift don't ask where to save the
> content, 
> but that's the exception and not the rule. 

I challenge you to back up this claim.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Wed, 2005-03-30 at 09:58 -0800, Casey Schaufler wrote:
> --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> 
> > Ok, some apps like gift don't ask where to save the
> > content, 
> > but that's the exception and not the rule. 
> 
> I challenge you to back up this claim.

I don't need to back up this claim, because:

1) Apps that don't let you configure where to save your content are
badly designed.

2) They can be changed

3) If they're not changed, it doesn't matter, because what I'm proposing
is backwards compatible. User_t will still have access to all content
types, and can write stuff to /home as user_home_t. Apps will have to be
specifically confined in order not to be able to write to user_home_t.
If some app is a problem, it can be left to run at user_home_t for now.

4) If apps store stuff in a hardcoded location, we can label that easily
with the proper context, unless it's hardcoded to /home or some other
shared place. 

Anyway, I am starting to get a better idea as to how this might work - 
see my response to Luke's message.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2005-03-30 at 09:04 -0800, Casey Schaufler
> wrote:
> > Well, the old unix way was for them to run as
> > a normal (unprivileged) user. No privilege, no
> > problem, right?
> 
> Did you miss the desktop talk at the SELinux
> symposium?  

The BOF? Oh, I was there. I have witnesses!

> TE (not DTE, different beast, ask me privately if
> you want a comparison
> paper) can operate transparently to the application,
> but you often can't
> achieve true least privilege without application
> modifications or
> changes in its conventional usage.  

Well, that will be a barrier to acceptance.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Stephen Smalley]

On Wed, 2005-03-30 at 09:53 -0800, Casey Schaufler wrote:
> The BOF? Oh, I was there. I have witnesses!

Not the X BOF, the talk by Colin Walters on securing the desktop.  See
the website for the slides if you missed it.

> > TE (not DTE, different beast, ask me privately if
> > you want a comparison
> > paper) can operate transparently to the application,
> > but you often can't
> > achieve true least privilege without application
> > modifications or
> > changes in its conventional usage.  
> 
> Well, that will be a barrier to acceptance.

It isn't a TE issue; it is just a least privilege issue in general.
Applications and usage patterns aren't accustomed to having to deal with
least privilege restrictions.  Hence, if you want to move towards least
privilege, some change is necessary.  But you can certainly configure TE
as coarsely as you want to avoid breaking any existing applications or
user behaviors, accepting the corresponding limitations in what security
you can provide.  Your choice...

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:
> On Wed, Mar 30, 2005 at 09:04:26AM -0800, Casey
> Schaufler wrote:
> 
> > Yes, and I'm sure that you can do a configuration
> > of most application defaults that will be good
> > enough to demo. Application developers tend to
> > have their own ideas regarding data storage and
> > it is a bad idea for a system developer to
> > interfere with said application developer's
> > freedom to inovate.
> 
>  ... application developer's freedom to impose
> insecurity,
>  through ignorance on the part of the app-developer,
> upon
>  the users?

What ignorance? The developer codes to the
published policies (e.g. uids, modes, capabilities)
and everything works *within the published policy*.
Some stranger comes along and without warning
arbitrarily imposes additional policy on the
application that the developer has so carefully
crafted, often without looking at the code to
see what the developer's intent might have been. 
 
>  no offense intended:

None taken. I buy skin thickener in 55 gallon drums.

> freedom in an abstract concept
> [e.g. "the american way"]
> _always_ has limits - laws / rules / policy
> is defined to confine
> that freedom, for good or worse.

Yup. So long as those limits can be known by
the "free" entity all is good. When additional
constraints can be added whimsically there is
bound to be resistance.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

--
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: Desktop apps interoperability

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> On Wed, 2005-03-30 at 07:52 -0800, Casey Schaufler
> wrote:
> > --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > > On Wed, 2005-03-30 at 07:05 -0800, Casey
> Schaufler
> > > wrote:
> > > ...
> > > > > Desktop apps will be restricted to only
> access
> > > the
> > > > > appropriate one.
> > > > > "Downloading" apps will be restricted to
> > > download to
> > > > > untrusted_content_t. 
> > > > 
> > > > Am I the only one wary of a slippery slope
> here?
> > > 
> > > What's the problem?
> > 
> > Unless I read your intent incorrectly (which
> > is possible) you're talking about requiring
> > the rearchitecting of the data storage schemes
> > for every user application on the planet to
> > accomodate the presence of DTE. And you're
> > talking about it as if it might actually happen.
> 
> Do you have a better proposal for restricting
> desktop applications
> to minimum privilege?

Well, the old unix way was for them to run as
a normal (unprivileged) user. No privilege, no
problem, right?

OKay, I know that's not being helpful.

I am concerned about the way y'all are going
about this. It appears that you are deriving
policy from behavior and then suggesting changes
to the behavior so that the policy makes sense.
While this is consistant with commercial software
development practice it is highly out of line
with secure system development practice. The
good reason to use policy derived from behavior
is to avoid changing existing applications.
If you are going to change the application you
will better serve the community by deciding first
what the policy ought to be then changing the
application to suit it rather than doing the
derive-tweek two step.

> Nothing needs to be rearchitectured. The user just
> needs
> to be made aware that this is where the documents
> belong, and
> the app can't write all over the place like it would
> in a non-selinux
> environment.

Yes, and I'm sure that you can do a configuration
of most application defaults that will be good
enough to demo. Application developers tend to
have their own ideas regarding data storage and
it is a bad idea for a system developer to
interfere with said application developer's
freedom to inovate.

> Apps that still run in user_t would be
> unaffected until
> their policy is changed.

But the policy change is being made for them,
outside the program, by people who's needs the
typical application developer is not considering.
Back to my point, the policy mechanism needs to
be either transparent to the application or
integral to it.

> Of course, I'm thinking in the future such folders
> would be prominently
> displayed in Gnome with their own little icons, and
> their windows-style
> names like "My Media" or whatever (which should not
> be the same 
> as the actual dir. name), and those would go in the
> Places menu or
> something, and sound juicer for example would know
> to write there by
> default as opposed to somewhere else. 

Chuckle. I worked on a scheme much like this.
On Unix. In 1980. It was not a popular product.

> I guess this discussion now becomes more
> GNOME-oriented, now that I
> think about it. Maybe I should go bother the GNOME
> people to see what
> they think about adding content-specific folders to
> /home that we can
> label with different contexts..

Yes.

> ... or am I missing something fundamental here? 

Is DTE application transparent or does it require
modification to the applications? If the latter
your proposals are reasonable but the whole DTE
scheme is more sophisticated than it needs to be.
If the former, you need to relax your expectations
of application behavior and work harder on the
policy you want to impose.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Stephen Smalley]

On Wed, 2005-03-30 at 09:04 -0800, Casey Schaufler wrote:
> Well, the old unix way was for them to run as
> a normal (unprivileged) user. No privilege, no
> problem, right?

Did you miss the desktop talk at the SELinux symposium?  
http://www.selinux-symposium.org/2005/presentations/session3/3-1-walters.pdf

> Is DTE application transparent or does it require
> modification to the applications? If the latter
> your proposals are reasonable but the whole DTE
> scheme is more sophisticated than it needs to be.
> If the former, you need to relax your expectations
> of application behavior and work harder on the
> policy you want to impose.

TE (not DTE, different beast, ask me privately if you want a comparison
paper) can operate transparently to the application, but you often can't
achieve true least privilege without application modifications or
changes in its conventional usage.  

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Wed, Mar 30, 2005 at 09:04:26AM -0800, Casey Schaufler wrote:

> Yes, and I'm sure that you can do a configuration
> of most application defaults that will be good
> enough to demo. Application developers tend to
> have their own ideas regarding data storage and
> it is a bad idea for a system developer to
> interfere with said application developer's
> freedom to inovate.

 ... application developer's freedom to impose insecurity,
 through ignorance on the part of the app-developer, upon
 the users?

 no offense intended: freedom in an abstract concept [e.g. "the american
 way"] _always_ has limits - laws / rules / policy is defined to confine
 that freedom, for good or worse.

 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: Desktop apps interoperability

[Ivan Gyurdiev]

On Wed, 2005-03-30 at 18:26 +0100, Luke Kenneth Casson Leighton wrote:
> On Wed, Mar 30, 2005 at 09:04:26AM -0800, Casey Schaufler wrote:
> 
> > Yes, and I'm sure that you can do a configuration
> > of most application defaults that will be good
> > enough to demo. Application developers tend to
> > have their own ideas regarding data storage and
> > it is a bad idea for a system developer to
> > interfere with said application developer's
> > freedom to inovate.
> 
>  ... application developer's freedom to impose insecurity,
>  through ignorance on the part of the app-developer, upon
>  the users?
> 
>  no offense intended: freedom in an abstract concept [e.g. "the american
>  way"] _always_ has limits - laws / rules / policy is defined to confine
>  that freedom, for good or worse.

I don't understand what this has to do with the application developer.
This is a discussion of desktop applications that manipulate content
relevant to the user - not internal settings. The settings that go
under /home are another issue - that would require changing the app,
but they don't have to be changed all at the same time. 

All those apps *ask* you where to store the content. You create a
document of some sort, and you have a choice of where to put it.
This has nothing to do with the app developer. It's just another
restriction imposed on the user. Hopefully there's a way to get 
away with it, while staying user-friendly. That's why I'm suggesting
content folders be introduced and integrated w/ GNOME's Places
menu, for example. That seems like a small first step to improving
things... no?

Ok, some apps like gift don't ask where to save the content, 
but that's the exception and not the rule. 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Jim McCullough]

There as been multiple instances on other lists where an "admin" or
"developer" has been totally ignorant of any type of security
practices.  Cases of do as I will and roll with the punches.  This
occurs on all platforms of development.   Freedom of implementation
should also require some common sense.  I like the content folders
Ivan suggested.   That would save people like me who are attention
defficiet a more structured schema for their fresh systems ( and prob.
save me a couple of hours on my own each build i have to do for myself
).
  
-- 
Jim McCullough

On Wed, 30 Mar 2005 12:44:22 -0500, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> On Wed, 2005-03-30 at 18:26 +0100, Luke Kenneth Casson Leighton wrote:
> > On Wed, Mar 30, 2005 at 09:04:26AM -0800, Casey Schaufler wrote:
> >
> > > Yes, and I'm sure that you can do a configuration
> > > of most application defaults that will be good
> > > enough to demo. Application developers tend to
> > > have their own ideas regarding data storage and
> > > it is a bad idea for a system developer to
> > > interfere with said application developer's
> > > freedom to inovate.
> >
> >  ... application developer's freedom to impose insecurity,
> >  through ignorance on the part of the app-developer, upon
> >  the users?
> >
> >  no offense intended: freedom in an abstract concept [e.g. "the american
> >  way"] _always_ has limits - laws / rules / policy is defined to confine
> >  that freedom, for good or worse.
> 
> I don't understand what this has to do with the application developer.
> This is a discussion of desktop applications that manipulate content
> relevant to the user - not internal settings. The settings that go
> under /home are another issue - that would require changing the app,
> but they don't have to be changed all at the same time.
> 
> All those apps *ask* you where to store the content. You create a
> document of some sort, and you have a choice of where to put it.
> This has nothing to do with the app developer. It's just another
> restriction imposed on the user. Hopefully there's a way to get
> away with it, while staying user-friendly. That's why I'm suggesting
> content folders be introduced and integrated w/ GNOME's Places
> menu, for example. That seems like a small first step to improving
> things... no?
> 
> Ok, some apps like gift don't ask where to save the content,
> but that's the exception and not the rule.
> 
> --
> Ivan Gyurdiev <ivg2@cornell.edu>
> Cornell University
> 
> 
> --
> 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.
>

--
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Wed, Mar 30, 2005 at 01:09:57PM -0500, Jim McCullough wrote:
> There as been multiple instances on other lists where an "admin" or
> "developer" has been totally ignorant of any type of security
> practices.  Cases of do as I will and roll with the punches.  This
> occurs on all platforms of development.   Freedom of implementation
> should also require some common sense.  I like the content folders
> Ivan suggested.   

 kdbfs.  modelled on the MAC OS/X "finder".  absolutely brilliant.

 a pity its back-end is implemented in ocaml.

 kdbfs is similar to famd / locate, only the author went a stage further
 and wrote a front-end that modifies the dialog boxes in KDE 3.2 [which
 i later ported to 3.3].

 the reason i mention it is because its default installation assumes
 that there exists ~/Applications, ~/Music, ~/Pictures etc, ~/Documents,
 ~/Video.

 what it does is, depending on the mime-type [file extension], it will
 present you with a file-save dialog box where there is NO CHOICE about
 where the [new] file you are saving goes.  IT WILL be saved in ~/Music
 if it has a .mpg extension.  IT WILL be saved in ~/Pictures if it has a
 .jpg extension.

 you get the idea.

 i loved it - but it wasn't integrated "enough" - unlike the MAC OS/X
 functionality it was trying to emulate.

 and unfortunately it's not a half-way-house solution: recompiling
 openoffice.org to use it for example was not an option [no KDE
 extensions available at the time, will have to wait for OO 2.0
 and _then_ specially recompile the KDE 3.3 or KDE 3.4 libs with
 the kdbfs patches... you get the idea]...

 
 basically, if there existed a linux distro which had kdbfs "rolled out"
 as an option, then it would be worthwhile having a kdbfs.te which
 defined an option that then enforced saving of files in these specific
 locations.

 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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Wed, Mar 30, 2005 at 12:44:22PM -0500, Ivan Gyurdiev wrote:
> On Wed, 2005-03-30 at 18:26 +0100, Luke Kenneth Casson Leighton wrote:
> > On Wed, Mar 30, 2005 at 09:04:26AM -0800, Casey Schaufler wrote:
> > 
> > > Yes, and I'm sure that you can do a configuration
> > > of most application defaults that will be good
> > > enough to demo. Application developers tend to
> > > have their own ideas regarding data storage and
> > > it is a bad idea for a system developer to
> > > interfere with said application developer's
> > > freedom to inovate.
> > 
> >  ... application developer's freedom to impose insecurity,
> >  through ignorance on the part of the app-developer, upon
> >  the users?
> > 
> >  no offense intended: freedom in an abstract concept [e.g. "the american
> >  way"] _always_ has limits - laws / rules / policy is defined to confine
> >  that freedom, for good or worse.
> 
> I don't understand what this has to do with the application developer.
 
 i must not understand the point, then.

> This is a discussion of desktop applications that manipulate content
> relevant to the user - not internal settings. 

 i believe it started out as internal settings [someone
 suggested a ~/.etc / registry etc solution e.g. gconfd]
 or maybe that was a different thread.  ... anyway.

> All those apps *ask* you where to store the content. 


 not necessarily - and, additionally, they typically have
 default locations where the content is asked to be stored,
 and the majority of users go "duhhhhhh, *click*".

 esp. windows users, for whom "duhhhh, *click*" means it ends
 up in "My Documents", or "The Desktop", etc. etc. and then
 they bitch like hell because they can't _find_ anything.


> Ok, some apps like gift don't ask where to save the content, 
> but that's the exception and not the rule. 

 some apps don't ask - but the "default" location is just as
 important, imo, as not being asked at all.

 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: Desktop apps interoperability

[Ivan Gyurdiev]

> 
> > This is a discussion of desktop applications that manipulate content
> > relevant to the user - not internal settings. 
> 
>  i believe it started out as internal settings [someone
>  suggested a ~/.etc / registry etc solution e.g. gconfd]
>  or maybe that was a different thread.  ... anyway.

(Re-adding fedora-selinux-list to cc - why was it removed?)

It's another part of the same problem - the internal settings are mixed
with the content, and that's bad. You can move the settings, move the
content, or both. Since the second is easier, that's what I suggest be 
done to begin with - later something can be done about settings.

The content folders should exist whether or not SElinux is installed, as
an organizational tool - there's no reason why mozilla should go and
clutter up my /home folder whether or not SELinux is involved - I never
liked that, which is why I always make a separate folder anyway, and put
stuff there. Apps should be configured to store things at their
particular content folder by default. Those folders should be in 
GNOME's Places menu.

The only controversial thing seems to be that I'm suggesting that they
can *only* write there, the SElinux-imposed restriction. 

I'm not sure that's such a huge problem.

Okay, here's how this is going to work - if you want to delete the
preinstalled music content folder, and put your things somewhere else,
music_content_t would be configured as a customizable context - all
those contexts should be customizable. That means they survive a
restorecon, among other things.

Then you can make a folder, and in nautilus you right click,
and you see the SELinux content (dwalsh has a patch for that).
Then I've wanted to modify that patch to have a drop-down box 
of customizable contexts for the user to choose from. I haven't gotten
around to doing that yet, but I think you should be able to right click
in nautilus, open up a drop-down box of contents, and pick: Media
(media_content_t), or whatever. Then after that your app will be able to
save to that folder too.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Ivan Gyurdiev]

> 
> Okay, here's how this is going to work - if you want to delete the
> preinstalled music content folder, and put your things somewhere else,
> music_content_t would be configured as a customizable context - all
> those contexts should be customizable. That means they survive a
> restorecon, among other things.
> 
> Then you can make a folder, and in nautilus you right click,
> and you see the SELinux content (dwalsh has a patch for that).
> Then I've wanted to modify that patch to have a drop-down box 
> of customizable contexts for the user to choose from. I haven't gotten
> around to doing that yet, but I think you should be able to right click
> in nautilus, open up a drop-down box of contents, and pick: Media
> (media_content_t), or whatever. Then after that your app will be able to
> save to that folder too.

Then for downloaded files, you can right-click and change their content
to whatever you want (list of customizables), or double-click on the
file, and GNOME does a mime-lookup on the file, and determines the
proper handler, and the proper context for that handler (like the other
person suggested)

Whenever you do that there could be a box saying something like:

"You are attempting to relabel potentially harmful content. 
 Are you sure you want to do this: Yes | No | Scan buttons 
 Checkbox: Do not ask again
 Checkbox: Perform a virus scan when opening file of this type"

... or something like that

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> How about
> 
> New Directory Structure (added to /skel, or
> whatever)
> ~/content - ROLE_content_t
> ...
> ~/content/export_p2p - ROLE_p2p_share_t
> 
> Desktop apps will be restricted to only access the
> appropriate one.
> "Downloading" apps will be restricted to download to
> untrusted_content_t. 

Am I the only one wary of a slippery slope here?


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Wed, 2005-03-30 at 07:05 -0800, Casey Schaufler wrote:
> --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > How about
> > 
> > New Directory Structure (added to /skel, or
> > whatever)
> > ~/content - ROLE_content_t
> > ...
> > ~/content/export_p2p - ROLE_p2p_share_t
> > 
> > Desktop apps will be restricted to only access the
> > appropriate one.
> > "Downloading" apps will be restricted to download to
> > untrusted_content_t. 
> 
> Am I the only one wary of a slippery slope here?

What's the problem?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Casey Schaufler]

--- Tom <tom@lemuria.org> wrote:
> On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan
> Gyurdiev wrote:
> > Part of the problem seems to be the way Linux apps
> treat /home, as the
> > place for everything. 
> 
> It doesn't. It treats $HOME as the only place that
> the user has
> permission to store his stuff. On a well-configured
> system, that
> assumption is correct.

Windows and MacOS are designed as single user systems.
Unix and Linux are designed as multiuser systems.
Configuring a Windows system for multiple 
concurrent users is quite painful. Configuring
unix for a single user seems unnecessarily difficult.

Interestly, when we did the B1/LSPP versions of 
unix the home directory model helped reduce the
problem of user sensitivity restrictions by
isolating the part of the directory hierarchy
that had to be customized for the user.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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

Desktop apps interoperability

[Ivan Gyurdiev]

Okay, mozilla's handling of saved files is a problem. Here's what it
does - files saved under ROLE_home_dir_t, or ROLE_home_t directories
turn to ROLE_mozilla_home_t via file_type_auto_trans.

Here's what gift does by default - it has a download folder where it
puts stuff. The downloaded files turn to ROLE_gift_home_t (context of
parent folder, which is ~/.giFT/completed or something).

Here's what mencoder does - it saves stuff as ROLE_mplayer_home_t
via file_type_auto_trans.

==============

This is bad for interoperability. Using the home_domain macro,
the user has access to the home_domain type of an application.
However one app has no access to the home_domain type of another app.
Basically I can never play (mplayer) a movie that I just downloaded,
whether or not it was via mozilla, or gift. 

Alternatively, there could be a common data type - ROLE_home_t.
However none of those apps can save its data directly
under /home/username as ROLE_home_t, because all of them have a
home_domain, and that's where the file_type_auto_trans rule is used.
There can't be more than one file_type_auto_trans on the same folder
type (right?). Furthermore this seems to be explicitly avoided for
mozilla (it does not write to ROLE_home_t for security reasons -
overwriting .bashrc?).

============

Ok, here


Fundamentally, what I want to know is:

1) Do desktop apps need to be confined? Is it a good idea to confine
them?

2) If so, a shared data type is needed for interoperability. 
Is ROLE_home_t acceptable for that purpose.

3) 

0) No 

1) Shared data type is needed for interoperability

2) Keeping both application settings, and user data in the same folder
is a problem




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Desktop apps interoperability

[Ivan Gyurdiev]

Okay that was an unfinished email - sorry for my stupidity - I was 
editing it and changing things and clicked send by mistake.

The problem is accurately described (in the first part of the email) and
what I was getting to - I'm trying to imagine how desktop apps can be
confined properly in the future (and right now, for that matter). How
will they interoperate and share data?

I was thinking of a ~/downloads folder with a shared context, but 
this makes sense for apps that download stuff. In the future if desktop
apps are confined (say openoffice, abiword) this becomes a more generic
problem.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 00:03 -0500, Ivan Gyurdiev wrote:
> Okay that was an unfinished email - sorry for my stupidity - I was 
> editing it and changing things and clicked send by mistake.
> 
> The problem is accurately described (in the first part of the email) and
> what I was getting to - I'm trying to imagine how desktop apps can be
> confined properly in the future (and right now, for that matter). How
> will they interoperate and share data?
> 
> I was thinking of a ~/downloads folder with a shared context, but 
> this makes sense for apps that download stuff. In the future if desktop
> apps are confined (say openoffice, abiword) this becomes a more generic
> problem.

Part of the problem seems to be the way Linux apps treat /home, as the
place for everything. Why are both app. settings and user data stored
in /home as the default location. That's where the problem comes from,
and that seems like a bad idea - the user doesn't care about app
settings and system files - they are not to be edited directly. That's
why they're hidden in the first place. 

Now Windows' approach of having "My Documents" and the like is starting
to make a lot of sense (even though I absolutely hate those names).

If app settings were kept separate, in a non-selinux environment you
could export your data files w/out exporting hidden important files like
your gpg keys. 

If app settings were kept separate, you could restorecon those settings
to correct contexts. Dwalsh said restorecon skips /home today because
it could accidentaly reveal out-of-place gpg keys, or because it might
be really big. Both those problems would not apply if settings were in a
separate place - you could just restorecon the settings.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:

> Now Windows' approach of having "My Documents" and the like is starting
> to make a lot of sense (even though I absolutely hate those names).

 and the concept of a registry, too.

 unix has a lot of legacy headaches to answer for that make its
 useability as a desktop system a pain in the neck.

 perhaps this is one that's worthwhile raising with the linux
 standards base people?

 if it doesn't present a solution "now" it might at least get one into
 the pipeline and start to make a difference in five to ten years time.

 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: Desktop apps interoperability

[Rogelio Serrano]

On Mon, 28 Mar 2005 11:01:40 +0100, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
> 
> > Now Windows' approach of having "My Documents" and the like is starting
> > to make a lot of sense (even though I absolutely hate those names).
> 
>  and the concept of a registry, too.
> 
>  unix has a lot of legacy headaches to answer for that make its
>  useability as a desktop system a pain in the neck.
> 
>  perhaps this is one that's worthwhile raising with the linux
>  standards base people?
> 
>  if it doesn't present a solution "now" it might at least get one into
>  the pipeline and start to make a difference in five to ten years time.
> 
>  l.
> 

NextStep and Mac OS X solved this problem very elegantly. IMHO.  


-- 
Blood is thicker than water... and much tastier
                                           John Davidorff Pell

--
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: Desktop apps interoperability

[Dale Amon]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

On Mon, Mar 28, 2005 at 06:17:14PM +0800, Rogelio Serrano wrote:
> On Mon, 28 Mar 2005 11:01:40 +0100, Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> > On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
> > 
> > > Now Windows' approach of having "My Documents" and the like is starting
> > > to make a lot of sense (even though I absolutely hate those names).
> > 
> >  and the concept of a registry, too.
> > 
> >  unix has a lot of legacy headaches to answer for that make its
> >  useability as a desktop system a pain in the neck.
> > 
> >  perhaps this is one that's worthwhile raising with the linux
> >  standards base people?
> > 
> >  if it doesn't present a solution "now" it might at least get one into
> >  the pipeline and start to make a difference in five to ten years time.
> > 
> >  l.
> > 
> 
> NextStep and Mac OS X solved this problem very elegantly. IMHO.  

I will run screaming if someone imports the registry
concept into Unix. You'll need full AI to get it right.
I managed a moderate size university network of NeXT's.
The admin interface seems nice at first... but it sucks
you in and then you find the problems with upgrades of
software; the problem that if you pulled the plug on 
UFS open files got corrupted... and guess what? The
netinfo files were almost always open! 

Keep it ASCII; keep it in seperate files. By all means
try to get application and daemon writers to standardize
on their parsing. Not that you ever will.

And has to My Documents? Yech. Every user has their
own private idea of what setups should exist. Users
are users and have their own little worlds; Root
is Root and never the twain shall meet. Except perhaps
with proper selinux controls...

Now I do wish there were a dotfile directory in each
home directory and everyone put the dotfiles in it
when they are created... but if wishes were fishes
I'd have a life time supply of fish'n'chips.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Desktop apps interoperability

[Stephen Smalley]

On Tue, 2005-03-29 at 12:33 +0100, Dale Amon wrote:
> I will run screaming if someone imports the registry
> concept into Unix.

Better start running then.  gconf is already being used as a registry,
and there is a linux registry aka elektra project as well.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Colin Walters]

On Tue, 2005-03-29 at 08:54 -0500, Stephen Smalley wrote:
> On Tue, 2005-03-29 at 12:33 +0100, Dale Amon wrote:
> > I will run screaming if someone imports the registry
> > concept into Unix.
> 
> Better start running then.  gconf is already being used as a registry,
> and there is a linux registry aka elektra project as well.

People very often confuse "the registry concept" with a specific
implementation which they may have had a bad experience with in the past
or have heard rumors of other people having a bad experience with.

Having some sort of sane mechanism for locating, managing, and
monitoring preferences is pretty critical to writing desktop
applications.  For example, one thing that GConf provides is
notification of preference changes.  This is a fundamental basis for a
lot of how GNOME's "instant-apply" feature works, e.g. if you change the
theme all apps automatically update.  Doing this kind of thing with
"text files" or whatever is going to be hackish at best.

To bring this discussion somewhat back on topic, Luke is right in that
in order to write a strong SELinux policy for desktop applications, we
really need to have fine-grained separation between user data (i.e.
OpenOffice documents), user preferences, highly sensitive data such as
GPG keys, and random other junk that apps dump in $HOME like error logs.

Also relating to the registry: Once we finish D-BUS, the plan is to make
GConf be a userspace object manager; for example, to allow Mozilla the
ability to read but not write the "http proxy" GConf key, or to disallow
it from reading the WEP keys that NetworkManager currently stores there
(which is wrong, but...).  Having fine-grained labeling on preference
keys is much nicer than granting user_mozilla_t access to user_home_t,
which grants kind of unconstrained read access to everything, and is
better than trying to maintain a text file per key in some hypothetical
"text file registry" just so that we can have individual labels on them.




--
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: Desktop apps interoperability

[Tom]

On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
> Part of the problem seems to be the way Linux apps treat /home, as the
> place for everything. 

It doesn't. It treats $HOME as the only place that the user has
permission to store his stuff. On a well-configured system, that
assumption is correct.


> Why are both app. settings and user data stored
> in /home as the default location. 

Because otherwise the user couldn't add or edit them.


> Now Windows' approach of having "My Documents" and the like is starting
> to make a lot of sense (even though I absolutely hate those names).

The Linux approach, however, allows much more flexibility.

If you want applications to share data, there are several ways to
accomplish that goal. Here's just a quick idea:

* add $HOME/Downloads as a directory
* give it its own type, maybe ROLE_downloads_t
* give mozilla permissions to write there, with file_type_auto_trans
* give mplayer permissions to the resulting files

voila, mplayer can now play stuff downloaded from the web, without
opening up the big hole of giving it permissions to all mozilla files.


Another solution, for a more paranoid environment would be adding a
virus/malware scanner domain that can read mozilla's files and write them 
out again (after checking and/or cleaning) as a regular ROLE_home_t
file. This would ensure that any files fully accessible in the home
directory have been scanned.



The point is - I may or may not want mplayer to play random stuff from
the web with potentially dangerous content. If you want to, evaluate
your security requirements and institute the appropriate solution.


-- 
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 13:26 +0200, Tom wrote:
> On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
> > Part of the problem seems to be the way Linux apps treat /home, as the
> > place for everything. 
> 
> It doesn't. It treats $HOME as the only place that the user has
> permission to store his stuff. On a well-configured system, that
> assumption is correct.

Ah, but that's not true. The user is actively encouraged to store stuff
in $HOME, and not elsewhere, because:

1) There's no other folder that exists. The average user makes use of
what's already there.

2) The GNOME desktop has a large home icon where you put your files.

3) All applications that have a save dialog open /home as the default.

4) It's designated as a place to store your files in the GNOME Places

5) There's no easy way to export files you care about (minus settings)
through Samba, while there is an automatic HOME share you get for /home.

6) From a SELinux viewpoint, why does the user domain *need* access
to /home's setting part at all? Those are files created w/out direct
user interaction. They could be made accessible to individual
application domains, without user_t selinux access. 

Anyway, more to the point:

7) I can't call file_type_auto_trans twice on the same folder.

> If you want applications to share data, there are several ways to
> accomplish that goal. Here's just a quick idea:
> 
> * add $HOME/Downloads as a directory
> * give it its own type, maybe ROLE_downloads_t
> * give mozilla permissions to write there, with file_type_auto_trans
> * give mplayer permissions to the resulting files

...that's what I already proposed, but I'm saying that:

A) In the future if all desktop apps are restricted, this folder will
have to become something more generic that doesn't have anything to do
with downloads. It would become the equivalent of a new /home where you
keep your files. Are there any plans to restrict desktop apps ?

B) Whatever is decided upon needs to work out of the box. It needs to be
the default way things work, as opposed to me having to jump through
hoops to make SElinux work. Otherwise the average user will just disable
any protection and not look back.

> voila, mplayer can now play stuff downloaded from the web, without
> opening up the big hole of giving it permissions to all mozilla files.

Actually now I remember mplayer actually does have access to mozilla
files... but as you say that is a hack, which shouldn't be there.
However mplayer doesn't have access to gift files, which is what I was
thinking of. 

> The point is - I may or may not want mplayer to play random stuff from
> the web with potentially dangerous content. If you want to, evaluate
> your security requirements and institute the appropriate solution.

This email was titled "Desktop apps interoperability". It implies that
we're talking about the average desktop, as opposed to a paranoid
environment. The average person does not know (or care) for evaluating
security requirements and dealing with selinux. He/she wants
transparency, but there's still value in using selinux.

If you choose to download the content in question, and choose to run
mplayer on it, then it seems to me that it should work without messing
with security contexts.

--------

In the short run a downloads folder sounds like a good idea to me.
If added to skel, and set as the default download folder for mozilla,
that would be an improvement, I think. 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Tom]

> > It doesn't. It treats $HOME as the only place that the user has
> > permission to store his stuff. On a well-configured system, that
> > assumption is correct.
> 
> Ah, but that's not true. The user is actively encouraged to store stuff
> in $HOME, and not elsewhere, because:

Because there are many reasons for that. The most important ones
in my book are:

* other locations might be mounted read-only
* /home may be a remote (e.g. NFS) mount
* various standards define what /usr or /var are for, and storing
  user-specific data is not on that list
* security - seperation between system and user data

That last one is the one that we don't want to break, on a SECURITY
ENHANCED Linux system least of all.



All your reasons except for #1 are really just consequences of the fact
that /home is where Unix users store their stuff.


> 6) From a SELinux viewpoint, why does the user domain *need* access
> to /home's setting part at all? Those are files created w/out direct
> user interaction. They could be made accessible to individual
> application domains, without user_t selinux access. 

These are files that are totally created with user interaction. Just
because Joe Dummy doesn't vi his .muttrc doesn't mean that I don't.

It also saves us the headache of writing a policy for each and every
file that stores something in $HOME - which means pretty much
everything that has an options or settings dialog.



> Anyway, more to the point:
> 
> 7) I can't call file_type_auto_trans twice on the same folder.

That is why I suggested a new folder for that specific purpose. I only
need one file_type_auto_trans there, namely when I store the stuff.

If I recall correctly, I had written a mozilla policy with such a
change a year or so ago.



> A) In the future if all desktop apps are restricted, this folder will
> have to become something more generic that doesn't have anything to do
> with downloads. 

Are you insane?
Generic folders are the bane of anything even resembling security.
Being _specific_ is what SELinux is all about. That's what the ENHANCED
means, if you strip away all the bullshit bingo words. MAC and RBAC are
just the means used.

Downloads, especially, deserve to be treated differently, as they are
data from untrusted sources.



> It would become the equivalent of a new /home where you
> keep your files. Are there any plans to restrict desktop apps ?

Define "restrict".

"Do their intended operation" - no, I don't think there are any plans
to prevent that.

"Mess at will with anything else in $HOME" - why yes, absolutely. If my
movie player has any reasons reading my mail preferences, I really want
to know them.



> B) Whatever is decided upon needs to work out of the box. It needs to be
> the default way things work, as opposed to me having to jump through
> hoops to make SElinux work. Otherwise the average user will just disable
> any protection and not look back.

There will be hoops. Just like putting on the safety belt when getting
into your car is one.

I'm sure everyone involved in SELinux development wants to avoid
unnecessary hoops. But some will be necessary, just like a firewall,
two virus scanners and a yearly reinstall are necessary on today's
windos systems.



> This email was titled "Desktop apps interoperability". It implies that
> we're talking about the average desktop, as opposed to a paranoid
> environment. The average person does not know (or care) for evaluating
> security requirements and dealing with selinux. He/she wants
> transparency, but there's still value in using selinux.

The average person also doesn't want their home machine turned into a
spammer zombie. At the current growth rate, the average person will
soon be faced with a few hard choices. I mean, you can't seriously buy 
Windows XP anymore, because you'll be infected with at least one malware
before the download of SP2 is finished. The only option is OEM versions
that already have at least SP2 applied.



> If you choose to download the content in question, and choose to run
> mplayer on it, then it seems to me that it should work without messing
> with security contexts.

Ah, but maybe you don't want mplayer to access everything you
downloaded?

In the long term, an explicit transfer (a nice GUI tool would make it
almost painless for the user. In fact, on a drag-and-drop desktop you
could probably add it to the drag&drop process) seems to be the better
solution.




-- 
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 15:11 +0200, Tom wrote:
> > > It doesn't. It treats $HOME as the only place that the user has
> > > permission to store his stuff. On a well-configured system, that
> > > assumption is correct.
> > 
> > Ah, but that's not true. The user is actively encouraged to store stuff
> > in $HOME, and not elsewhere, because:
> 
> Because there are many reasons for that. The most important ones
> in my book are:
> 
> * other locations might be mounted read-only
> * /home may be a remote (e.g. NFS) mount
> * various standards define what /usr or /var are for, and storing
>   user-specific data is not on that list
> * security - seperation between system and user data

I was suggesting that content should be kept in a sub-folder of /home,
not that it should be kept somewhere else. I'm sorry for the
misunderstanding. I am suggesting that this folder(s) should be
standartized somehow. I am saying that settings should be kept separate.

> > 6) From a SELinux viewpoint, why does the user domain *need* access
> > to /home's setting part at all? Those are files created w/out direct
> > user interaction. They could be made accessible to individual
> > application domains, without user_t selinux access. 
> 
> These are files that are totally created with user interaction. Just
> because Joe Dummy doesn't vi his .muttrc doesn't mean that I don't.

That's a valid point - and the way home_domain macro currently works 
is that it allows the user to access the data. Anyway, I still think
there's advantages to keeping settings separate from "content".


> > Anyway, more to the point:
> > 
> > 7) I can't call file_type_auto_trans twice on the same folder.
> 
> That is why I suggested a new folder for that specific purpose. I only
> need one file_type_auto_trans there, namely when I store the stuff.
> 
> If I recall correctly, I had written a mozilla policy with such a
> change a year or so ago.

So let's add this folder to /skel with the appropriate context
(*different* from the current ROLE_mozilla_home_t), and make it the
default for mozilla. See what I write elsewhere first tho.

> > A) In the future if all desktop apps are restricted, this folder will
> > have to become something more generic that doesn't have anything to do
> > with downloads. 
> 
> Are you insane?
> Generic folders are the bane of anything even resembling security.
> Being _specific_ is what SELinux is all about. That's what the ENHANCED
> means, if you strip away all the bullshit bingo words. MAC and RBAC are
> just the means used.

... that's a valid point, but how do you suggest interoperability should
be addressed? When I say "generic" I don't mean that it should be used
for everything under the Sun. I mean something that makes sense.
Right now most of the system uses user_home_t anyway - that seems pretty
generic to me.

> Downloads, especially, deserve to be treated differently, as they are
> data from untrusted sources.

... all the more reason to put them in their own folder location.

> > It would become the equivalent of a new /home where you
> > keep your files. Are there any plans to restrict desktop apps ?
> 
> Define "restrict".

I mean make them run in their own domain with minimum priviledge
required to operate, as opposed to running in user_t. I do not 
mean that they should be unable to perform their intended operation.

> "Mess at will with anything else in $HOME" - why yes, absolutely. If my
> movie player has any reasons reading my mail preferences, I really want
> to know them.

Well, as of right now your movie player has the ability to read
user_home_t, as a possible source of movies to play. I can't remember
whether it was mplayer or xine that had the capability to act as a movie
server, but I know one of them did. Now they can transmit .bashrc, and
who knows what over the net. 

Say I rip a bunch of songs with sound-juicer. Now I want to share them
with gift (p2p app). I can't make that work out of the box without
changing the context, because gift can't read user_t files. If the songs
went into a common "content"-style folder, I could make that readable by
gift, mplayer, and whatever needs it, and make them stay away from
user_t.

> 
> > B) Whatever is decided upon needs to work out of the box. It needs to be
> > the default way things work, as opposed to me having to jump through
> > hoops to make SElinux work. Otherwise the average user will just disable
> > any protection and not look back.
> 
> There will be hoops. Just like putting on the safety belt when getting
> into your car is one.
> 
> I'm sure everyone involved in SELinux development wants to avoid
> unnecessary hoops. But some will be necessary, just like a firewall,
> two virus scanners and a yearly reinstall are necessary on today's
> windos systems.

I don't think so. The hoops are unnecessary, and the problem can be
solved nicely to fit all people's needs. What you're telling me is that
I shouldn't bother with SElinux anymore -  my main motivation for
playing with this technology at all is that it's applicable to my home
machine - not some ultrasecure server in a basement. I want something 
usable that can improve security at the same time.


> > This email was titled "Desktop apps interoperability". It implies that
> > we're talking about the average desktop, as opposed to a paranoid
> > environment. The average person does not know (or care) for evaluating
> > security requirements and dealing with selinux. He/she wants
> > transparency, but there's still value in using selinux.
> 
> The average person also doesn't want their home machine turned into a
> spammer zombie. At the current growth rate, the average person will
> soon be faced with a few hard choices. I mean, you can't seriously buy 
> Windows XP anymore, because you'll be infected with at least one malware
> before the download of SP2 is finished. The only option is OEM versions
> that already have at least SP2 applied.

What's the point that you're trying to make?
If you're implying that security is more important than usability, then
I'm not convinced. 

> > If you choose to download the content in question, and choose to run
> > mplayer on it, then it seems to me that it should work without messing
> > with security contexts.
> 
> Ah, but maybe you don't want mplayer to access everything you
> downloaded?
 
That's a tradeoff I'm inclined to accept - especially since mplayer can
stream stuff off the net itself.

> In the long term, an explicit transfer (a nice GUI tool would make it
> almost painless for the user. In fact, on a drag-and-drop desktop you
> could probably add it to the drag&drop process) seems to be the better
> solution.

How exactly will that work - some details?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Tom]

On Mon, Mar 28, 2005 at 08:46:24AM -0500, Ivan Gyurdiev wrote:
> I was suggesting that content should be kept in a sub-folder of /home,
> not that it should be kept somewhere else. I'm sorry for the
> misunderstanding. I am suggesting that this folder(s) should be
> standartized somehow. I am saying that settings should be kept separate.

ah! What you want is /home/tom/.etc/ ?



> > Generic folders are the bane of anything even resembling security.
> > Being _specific_ is what SELinux is all about. That's what the ENHANCED
> > means, if you strip away all the bullshit bingo words. MAC and RBAC are
> > just the means used.
> 
> ... that's a valid point, but how do you suggest interoperability should
> be addressed? When I say "generic" I don't mean that it should be used
> for everything under the Sun. I mean something that makes sense.

I posted my vision below - an explicit transfer. True, you can still
trick the user, but it stops any automated exploits.


> > Downloads, especially, deserve to be treated differently, as they are
> > data from untrusted sources.
> 
> ... all the more reason to put them in their own folder location.

As I suggested. :)



> > > It would become the equivalent of a new /home where you
> > > keep your files. Are there any plans to restrict desktop apps ?
> > 
> > Define "restrict".
> 
> I mean make them run in their own domain with minimum priviledge
> required to operate, as opposed to running in user_t. I do not 
> mean that they should be unable to perform their intended operation.

Then yes, I do believe many programs should be restricted. Anything
with outside contact (web browser, mail reader, etc.) most definitely.


> Say I rip a bunch of songs with sound-juicer. Now I want to share them
> with gift (p2p app). I can't make that work out of the box without
> changing the context, because gift can't read user_t files. If the songs
> went into a common "content"-style folder, I could make that readable by
> gift, mplayer, and whatever needs it, and make them stay away from
> user_t.

I'm still opposed to a generic "content" directory. However, what about
a generic "share" directory with proper auto_trans rules? Anything I
explicitly move there is readable by anything that knows what read()
ist.



> I don't think so. The hoops are unnecessary, and the problem can be
> solved nicely to fit all people's needs. What you're telling me is that
> I shouldn't bother with SElinux anymore -  my main motivation for
> playing with this technology at all is that it's applicable to my home
> machine - not some ultrasecure server in a basement. I want something 
> usable that can improve security at the same time.

SELinux is incredible flexible. It can be configured totally insecure,
if you want. :)



> > The average person also doesn't want their home machine turned into a
> > spammer zombie. At the current growth rate, the average person will
> > soon be faced with a few hard choices. I mean, you can't seriously buy 
> > Windows XP anymore, because you'll be infected with at least one malware
> > before the download of SP2 is finished. The only option is OEM versions
> > that already have at least SP2 applied.
> 
> What's the point that you're trying to make?
> If you're implying that security is more important than usability, then
> I'm not convinced. 

I'm implying that jumping through hoops for security reasons is
becoming generally accepted. Most dummy users know that they need a
virus scanner. They have no idea what it is, except that it somehow
protects them from viruses. In fact, most dummy users I've talked to
don't know the difference between a firewall and a virus scanner.
However, they are quite willing to put up with whatever inconvenience
the virus scanner is putting on them, because the point that it's
necessary has been hammered home.

Why should Linux be any different?
"Ok, aunt Ellie, this is a Linux system. It doesn't need a virus
scanner like your windos system did, but [add whatever we finally agree
on as the user-friendly-and-still-safe method]"



> That's a tradeoff I'm inclined to accept - especially since mplayer can
> stream stuff off the net itself.

Not if you don't want. That's the beauty of SELinux - I don't care how
many kitchen sinks they've built into their software, on _my_ system it
does what I allow it to do and nothing else.


> > In the long term, an explicit transfer (a nice GUI tool would make it
> > almost painless for the user. In fact, on a drag-and-drop desktop you
> > could probably add it to the drag&drop process) seems to be the better
> > solution.
> 
> How exactly will that work - some details?

Aunt Ellie downloads a movie. It goes into the Download folder (or
really anywhere, it doesn't matter much). She drags the movie icon to
the movie player and lets it drop. Movie plays.

Behind the scenes, the file is relabeled or moved into another
directory where mplayer can access it.

Why is this more secure? Because it requires the intervention of a
"trusted 3rd party" (the desktop environment) so you can not force bad
data on my mplayer by compromising Firefox. You can not, for example,
create movie-player-popup ads.



-- 
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: Desktop apps interoperability

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 16:09 +0200, Tom wrote:
> On Mon, Mar 28, 2005 at 08:46:24AM -0500, Ivan Gyurdiev wrote:
> > I was suggesting that content should be kept in a sub-folder of /home,
> > not that it should be kept somewhere else. I'm sorry for the
> > misunderstanding. I am suggesting that this folder(s) should be
> > standartized somehow. I am saying that settings should be kept separate.
> 
> ah! What you want is /home/tom/.etc/ ?

Something like that - yes.


> Aunt Ellie downloads a movie. It goes into the Download folder (or
> really anywhere, it doesn't matter much). She drags the movie icon to
> the movie player and lets it drop. Movie plays.
> 
> Behind the scenes, the file is relabeled or moved into another
> directory where mplayer can access it.

How does this relate to the SElinux work to secure the X server?
Should the desktop environment be trusted?

.. so what you're saying is that nautilus (running as user_t, which has
read access to the file in question, as well as appropriate relabel
access), should determine its mime type, or use the DND target app, and
associate a context with that, which the mime handler can play, then
relabel file to that context (can't copy - what if it's huge?).... and
do this for every mime handler I attempt to open it with?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 10:05 -0500, Ivan Gyurdiev wrote:
> .. so what you're saying is that nautilus (running as user_t, which has
> read access to the file in question, as well as appropriate relabel
> access), should determine its mime type, or use the DND target app, and
> associate a context with that, which the mime handler can play, then
> relabel file to that context (can't copy - what if it's huge?).... and
> do this for every mime handler I attempt to open it with?

Seems fairly pointless to perform such a relabeling if the context
determination is based entirely on untrusted input from the same source
as the data itself and the user isn't involved to any greater degree
than selecting the file in the first place.  If you are going to run it
through a filtering pipeline (e.g. malicious code checker), then it
makes more sense to set up a relabeling or data copying pipeline using
TE to ensure that each filter stage is unbypassable and tamperproof
(i.e. an assured pipeline in TE parlance).  Note however that relabeling
in place is not necessarily safe, as Linux does not yet fully support
revocation of access.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Tom]

On Mon, Mar 28, 2005 at 10:12:30AM -0500, Stephen Smalley wrote:
> Seems fairly pointless to perform such a relabeling if the context
> determination is based entirely on untrusted input from the same source
> as the data itself and the user isn't involved to any greater degree
> than selecting the file in the first place.

Not so sure about the pointlessness here. The point is that it makes it
more difficult to leverage exploits. Maybe I can break into Firefox,
but with that in place I can't jump from there to mplayer by forcing it
to play something I know will break it.

Lots and lots of system compromises I know about took more than one
exploit and more than one program needed to be broken.


Nevertheless, an explicit "good file" filter is certainly added value.
It doesn't have to be a full-blown virus scanner - on a proper SELinux
system I would expect any unexpected behaviour in mplayer to be
contained. Nevertheless, the filter should at least check whether the
data in question is what it claims to be. No need to port the nightmare
of .doc files that really are .exe or whatever to Linux.



-- 
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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 17:47 +0200, Tom wrote:
> Not so sure about the pointlessness here. The point is that it makes it
> more difficult to leverage exploits. Maybe I can break into Firefox,
> but with that in place I can't jump from there to mplayer by forcing it
> to play something I know will break it.

I'm not sure I understand your intent.  There are two scenarios:
1) mplayer directly launched by firefox.  As the attacker already has
control of the firefox process, the only possible benefit of
compromising a mplayer process launched by firefox is if it has further
permissions needed to achieve his end goal.  And how you prevent such
abuse of a directly launched mplayer is unclear, e.g. do you intend
firefox to engage in an IPC interaction with a process in the desktop
session to ask for the downloaded file to be relabeled prior to
launching mplayer on it?
2) mplayer launched by something other than firefox, e.g. user shell,
nautilus, after prior download of content via firefox.  At this point,
the user has explicitly selected the downloaded file, thus expressing
his intent (modulo any subversion of the user process itself, which is a
separate issue), and can hopefully be trusted not to open files that he
didn't download explicitly (if not, then how can he be trusted to make
decisions about relabeling)?  Hence, in this scenario, the relabeling
doesn't express the user intent any better than the selection by the
user of the downloaded file.  Naturally, what you really want there is a
trusted path mechanism.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Tom]

On Mon, Mar 28, 2005 at 11:04:26AM -0500, Stephen Smalley wrote:
> I'm not sure I understand your intent.  There are two scenarios:
> 1) mplayer directly launched by firefox.  As the attacker already has
[...]
> 2) mplayer launched by something other than firefox, e.g. user shell,
[...]
> user of the downloaded file.  Naturally, what you really want there is a
> trusted path mechanism.

Hmm.
I think you are right. I did forget about programs launching other
programs. On the other hand, doesn't that give us another option within
SELinux? Can't we make mplayer-launched-by-firefox run in a different
domain than mplayer-run-by-user? In that domain, it would have access
to the downloaded files, but not to the remainder of the user data.


-- 
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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 18:20 +0200, Tom wrote:
> I think you are right. I did forget about programs launching other
> programs. On the other hand, doesn't that give us another option within
> SELinux? Can't we make mplayer-launched-by-firefox run in a different
> domain than mplayer-run-by-user? In that domain, it would have access
> to the downloaded files, but not to the remainder of the user data.

Yes, that would make sense to me.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Ivan Gyurdiev]

How about

New Directory Structure (added to /skel, or whatever)
~/content - ROLE_content_t
~/content/desktop - ???
~/content/downloads - ROLE_untrusted_content_t
~/content/media - ROLE_media_content_t
~/content/documents - ROLE_documents_content_t
~/content/mail - ROLE_mail_content_t
~/content/export_web - ROLE_httpd_user_content_t
~/content/export_samba - ROLE_samba_share_t
~/content/export_p2p - ROLE_p2p_share_t

Desktop apps will be restricted to only access the appropriate one.
"Downloading" apps will be restricted to download to
untrusted_content_t. 

Now...how to move things to/from ~/content/downloads in a nice
user-friendly way? What context for desktop? What role will the desktop
play?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Desktop apps interoperability

[Tom]

On Mon, Mar 28, 2005 at 10:05:58AM -0500, Ivan Gyurdiev wrote:
> > ah! What you want is /home/tom/.etc/ ?
> 
> Something like that - yes.

Ok, that's a good idea.



> > Behind the scenes, the file is relabeled or moved into another
> > directory where mplayer can access it.
> 
> How does this relate to the SElinux work to secure the X server?

Not at all. X doesn't come in here. There's no reason why I can't do
something similar in non-X environments.


> Should the desktop environment be trusted?

Everything is trusted - to a degree. Can I trust my desktop environment
to relabel one filetype to one other filetype? For a military system
the answer would be no, but for a desktop system I think that's a risk
we can take.


> .. so what you're saying is that nautilus (running as user_t, which has
> read access to the file in question, as well as appropriate relabel
> access), should determine its mime type, or use the DND target app, and
> associate a context with that, which the mime handler can play, then
> relabel file to that context (can't copy - what if it's huge?).... and
> do this for every mime handler I attempt to open it with?

You could do priviledge seperation and have a relabeling demon running
in the background.

There's a dozen ways to do it. I really don't care much about which
exactly is used. The point I'm adamant about is two-fold: a) no generic
directories accesable by anyone and their dog - b) explicit transfers
through user interaction are a good idea. Not everything should be
transparent. Firefox's "hey, you downloaded this .exe from the 'net,
you sure you really wanna run it?" is a _good_ idea.



-- 
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:

> There can't be more than one file_type_auto_trans on the same folder
> type (right?). 

 bizarrely, no.

 i believe this issue was raised some months ago, with the
 "alternative file context" thing.

 if file_type_auto_trans also took an executable [domain] as an
 additional argument, i believe you stand a chance of achieving
 what you seek.

 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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 11:04 +0100, Luke Kenneth Casson Leighton wrote:
> On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:
> 
> > There can't be more than one file_type_auto_trans on the same folder
> > type (right?). 
> 
>  bizarrely, no.
> 
>  i believe this issue was raised some months ago, with the
>  "alternative file context" thing.
> 
>  if file_type_auto_trans also took an executable [domain] as an
>  additional argument, i believe you stand a chance of achieving
>  what you seek.

file_type_auto_trans() is based on the domain of the creating process,
the type of the parent directory, and optionally the class of the new
file.  Hence, you can specify different types on the same "folder" type
as long as the programs run in different domains.  If instead both
programs run in the same domain and are acting on the same directory
type and creating the same class of file, you have to make the program
security-aware if you want to use multiple types on the files (or
similarly, if you have a single program that creates multiple files in
the same directory and you want them to have different types, the
program needs to be security-aware, as with the /etc/passwd
and /etc/shadow type preservation issue).

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 08:36:32AM -0500, Stephen Smalley wrote:
> On Mon, 2005-03-28 at 11:04 +0100, Luke Kenneth Casson Leighton wrote:
> > On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:
> > 
> > > There can't be more than one file_type_auto_trans on the same folder
> > > type (right?). 
> > 
> >  bizarrely, no.
> > 
> >  i believe this issue was raised some months ago, with the
> >  "alternative file context" thing.
> > 
> >  if file_type_auto_trans also took an executable [domain] as an
> >  additional argument, i believe you stand a chance of achieving
> >  what you seek.
> 
> file_type_auto_trans() is based on the domain of the creating process,
> the type of the parent directory, and optionally the class of the new
> file.  

 brain-lapse.  of course it is.  duh.

> [description of how to make programs security-aware]

 so the issue ivan describes _can_ be solved.

 ... question: in what ways do you ensure that a security-aware
 compromised program is only allowed to create certain filetypes?

 is it to do with using compute_av()?

 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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 19:27 +0100, Luke Kenneth Casson Leighton wrote:
>  ... question: in what ways do you ensure that a security-aware
>  compromised program is only allowed to create certain filetypes?

In the same manner as with a security-unaware program; the domain must
be allowed create permission to the file type via an allow rule.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 01:23:39PM -0500, Stephen Smalley wrote:
> On Mon, 2005-03-28 at 19:27 +0100, Luke Kenneth Casson Leighton wrote:
> >  ... question: in what ways do you ensure that a security-aware
> >  compromised program is only allowed to create certain filetypes?
> 
> In the same manner as with a security-unaware program; the domain must
> be allowed create permission to the file type via an allow rule.
 
 ... there's nothing special needed? ... 
 
 oh - yes, i get it.  create filetype.
 nothing to do with file_type_auto_trans itself.

 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: Desktop apps interoperability

[Stephen Smalley]

On Mon, 2005-03-28 at 20:54 +0100, Luke Kenneth Casson Leighton wrote:
>  ... there's nothing special needed? ... 
>  
>  oh - yes, i get it.  create filetype.
>  nothing to do with file_type_auto_trans itself.

file_type_auto_trans() is a macro that expands to file_type_trans() and
a type_transition rule specifying the default type for the new files.
file_type_trans() is a macro that expands to the set of allow rules
needed for the domain to create the file (including appropriate
permissions to the parent directory as well as to the file).  The allow
rules are always needed for such a file creation to occur.  The
type_transition rule specifies a default in the absence of anything
specified by the program via setfscreatecon(3).  The ability to use
setfscreatecon(3) does require that the domain have one additional
permission, setfscreate, but the permission checks governing the actual
file creation are the same.

This is a general principle in SELinux; the same set of permission
checks are applied for operations regardless of whether the type was
application-specified or a default value, so that you can always
determine what is permissible via the allow rules.  The same is true of
exec transitions for processes.  The set of permission checks doesn't
change; only the types involved change.
 
-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Desktop apps interoperability

[Stephen Smalley]

On Sun, 2005-03-27 at 23:57 -0500, Ivan Gyurdiev wrote:
> Fundamentally, what I want to know is:
> 
> 1) Do desktop apps need to be confined? Is it a good idea to confine
> them?

Yes.

> 2) If so, a shared data type is needed for interoperability. 
> Is ROLE_home_t acceptable for that purpose.

A shared data type may be fine, but ROLE_home_t isn't what you want to
use.  And yes, separating settings from data is useful, and yes,
littering user's top-level home directories with application settings
considered harmful. 

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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.