Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Desktop apps interoperability Date: Sun, 27 Mar 2005 23:57:35 -0500
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:
3) 0) No
-- 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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 00:03:32 -0500
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.
--
-- subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 00:27:31 -0500
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 11:01:40 +0100
> Now Windows' approach of having "My Documents" and the like is starting 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.From: Rogelio Serrano <rogelio.serrano_at_gmail.com> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 18:17:14 +0800
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.From: Dale Amon <amon_at_vnl.com> subject: Re: Desktop apps interoperability Date: Tue, 29 Mar 2005 12:33:21 +0100
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" ------------------------------------------------------From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Tue, 29 Mar 2005 08:54:17 -0500
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Desktop apps interoperability Date: Tue, 29 Mar 2005 10:39:58 -0500
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 13:26:54 +0200
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 Because otherwise the user couldn't add or edit them.
> Now Windows' approach of having "My Documents" and the like is starting 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:
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 07:15:29 -0500
Ah, but that's not true. The user is actively encouraged to store stuff in $HOME, and not elsewhere, because:
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 ...that's what I already proposed, but I'm saying that:
> voila, mplayer can now play stuff downloaded from the web, without 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 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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 15:11:26 +0200
Because there are many reasons for that. The most important ones in my book are:
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 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: 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
Are you insane?
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 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 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 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 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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 08:46:24 -0500
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 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: 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 ... 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 ... all the more reason to put them in their own folder location.
> > It would become the equivalent of a new /home where you 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 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.
> 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 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 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 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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 16:09:36 +0200
ah! What you want is /home/tom/.etc/ ?
> > Generic folders are the bane of anything even resembling security. 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 As I suggested. :)
> > > It would become the equivalent of a new /home where you 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 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 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 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?
> That's a tradeoff I'm inclined to accept - especially since mplayer can 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 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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 10:05:58 -0500
Something like that - yes.
> Aunt Ellie downloads a movie. It goes into the Download folder (or 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 10:12:30 -0500
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 17:47:54 +0200
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 11:04:26 -0500
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?
-- 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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 18:20:20 +0200
Hmm.
-- 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 11:39:33 -0500
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 00:01:06 -0500
New Directory Structure (added to /skel, or whatever)
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 17:41:00 +0200
Ok, that's a good idea.
> > Behind the scenes, the file is relabeled or moved into another 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 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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 11:04:49 +0100
> There can't be more than one file_type_auto_trans on the same folder 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 08:36:32 -0500
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 19:27:14 +0100
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 13:23:39 -0500
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 20:54:50 +0100
... there's nothing special needed? ...
oh - yes, i get it. create filetype.
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 14:46:06 -0500
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 08:43:39 -0500
Yes.
> 2) If so, a shared data type is needed for interoperability. 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Mon, 28 Mar 2005 08:51:09 -0800 (PST)
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
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 07:05:24 -0800 (PST)
Am I the only one wary of a slippery slope here?
Casey Schaufler
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 10:29:06 -0500
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 07:52:07 -0800 (PST)
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
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 11:13:24 -0500
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 23:50:11 +0200
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 23:12:46 +0100
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 10:37:36 +0200
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 11:05:33 +0100
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:
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 03:42:47 -0500
> People who use Linux for their desktop usually enjoy one thing: That 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 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 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 09:04:26 -0800 (PST)
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 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 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 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 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
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 18:26:30 +0100
> Yes, and I'm sure that you can do a configuration ... 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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 12:44:22 -0500
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.From: Jim McCullough <jim.mccullough_at_gmail.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 13:09:57 -0500
-- Jim McCullough On Wed, 30 Mar 2005 12:44:22 -0500, Ivan Gyurdiev <ivg2@cornell.edu> wrote:From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 23:09:47 +0100
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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 23:00:18 +0100
i must not understand the point, then.
> This is a discussion of desktop applications that manipulate content 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, 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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 04:25:19 -0500
> (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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 04:48:53 -0500
> 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
... 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 12:15:22 -0500
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 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 09:27:51 -0800 (PST)
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 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
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 09:53:37 -0800 (PST)
The BOF? Oh, I was there. I have witnesses!
> TE (not DTE, different beast, ask me privately if Well, that will be a barrier to acceptance.
Casey Schaufler
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 12:56:20 -0500
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 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Wed, 30 Mar 2005 09:58:36 -0800 (PST)
> Ok, some apps like gift don't ask where to save the I challenge you to back up this claim.
Casey Schaufler
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 05:04:40 -0500
I don't need to back up this claim, because:
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 08:05:46 -0800 (PST)
Of course you don't need to back up the claim.
> 1) Apps that don't let you configure where to save 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, But ...
> Apps will have to be ... 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 You're right.
> Anyway, I am starting to get a better idea as to how
Will have a look. BTW, good work.
Casey Schaufler
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 11:08:07 -0500
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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 23:13:00 +0200
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 16:05:52 -0500
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.From: Rogelio Serrano <rogelio.serrano_at_gmail.com> subject: Re: Desktop apps interoperability Date: Fri, 1 Apr 2005 13:28:29 +0800
Unchangeable legacy apps should die.
> Sure, and at that point, you just confine it as best as you can while 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.From: Tom <tom_at_lemuria.org> subject: Re: Desktop apps interoperability Date: Fri, 1 Apr 2005 09:54:27 +0200
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.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 12:40:01 -0500
> > 3) If they're not changed, it doesn't matter, 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 08:51:16 -0800 (PST)
Oooooh! Sarcasm!
Existing MLS systems allow unprivileged
> No thanks, Ah, and the horse you rode in on.
Casey Schaufler
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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Desktop apps interoperability Date: Thu, 31 Mar 2005 13:16:50 -0500
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Fri, 1 Apr 2005 19:50:16 -0800 (PST)
> Unchangeable legacy apps should die. Get on the phone to RMS! Get gnu cracking!
> 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 Except when it works the way it is now?
> Therefore in an open source Bah! (waves paw)
Casey Schaufler
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Desktop apps interoperability Date: Sun, 3 Apr 2005 16:39:23 -0700 (PDT)
This is critically important to the possibility of widespread acceptance of the system.
> But there can be benefit from modifying applications 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
True enough. Nonetheless, the operating
Casey Schaufler
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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |