MacOS’ bird process creates a cache folder containing a lot of files with no meaningful names, ok. Gotten used to it.
Recently I noticed that some of these files being applications had been entered into security access system panel, claiming access to mic, camera, files etc.
I’ve never seen something like this before and removed their rights, obviously without consequences to my iMac’s behavior.
Is this a normal behavior? Or should I be worried?
Related
An application we're developing for a customer is running more or less fine on our internal development servers (V 8.5.3 with UP1 and FP5 as well as a secondary V 9). Our development is done using V 9 designer clients.
Yesterday we pushed a test version onto the customer's server (V 8.5.3 FP5 / UP1). The result rendered by their server however is completely different from what we get from our servers. It turns out that only custom style sheets are rendered while everything that usually should be coming from the server's webstandard theme is completely missing: no xsp.css, xsp_ie.css and the likes. Thus the pages are completely unusable: tabbed panels are rendered as standard elements, rich text editors are completely broken, just to name a few things.
We had the local admins check the server file system: webstandard theme appears to be there, and accessible to everyone.
Has anyone ever come across something like that? In 4 years of developing Xpages I've never seen something like that, at the moment I'm completely clueless in what to try next.
I really hope that this is just a minor flaw easy to be resolved.
Lothar
Have you checked the installation? I have seen servers that were upgraded the wrong way by copying the data directory, then upgrading and then moving back the data old directory, thus overwriting some important files or even loosing important files and directories...
This is hilarious: for security reasons the customer's admins deleted all files from the server's file system that they thought weren't needed. For some reasons they left the themes but removed all resources like css and js files (including all dojo dirs). No, I won't tell any names.
Lesson learned: never just assume a customer's setup to be fully functional until this fact is properly proved ;)
I'm making a webpage in Drupal 6.26, and I blocked in a strange thing. I develop both in Localhost, and online, and the strange is that some how in online the primary links are empty (but there's element on it I can see in /admin/build/menu-customize/primary-links also in this page the menu elements appeared in the place, but in the other pages they don't), but in Localhost everything is ok, and i checked all of the settings and they are the same, the theme files are the same to,(and i didn't change anything in the other drupal files), the only difference is that the online page is set in offline (because the under maintenance), and I tried it to make it online, but the problem is still there, so I don't really have any idea.
That might be a theme problem. Make sure your local configuration has the same active theme as the installation on the public server. Try switching to a default theme that comes with Drupal.
Another cause might be one of your modules. Try disabling all but the system modules and then start re-enabling them one-by-one to see which one changes your menu.
am I just stupid or does Drupal have a big flaw? (probablt the former of the two..)
I have built a site with some public content and some private content. The problem is that even though menus can be hidden from public, unauthorized users, there is no stopping a visitor from just typing in node/5 (if node/5 were one of the private, hidden pages).
And I am baffled by how troublesome this is to fix. there is no basic functionality to fix this, and having tried two modules simple_access and access_control none of them work! Currently trying to fix a drupal 6 site. Any suggestions on modules that might fix this VERY BASIC functionality? Is Drupal not meant to handle corporate pages where you have external pages and internal sensitive content?
By the way, Drupal 7 is in the .9 stage, there are still VERY limited module availability, mostly everything is in an alpha stage and has been like forever, is there no development being done for D7?
The module that'll fix the problem for you is Nodeaccess; this is the opening text from the module page:
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role.
So that will do exactly what you want. Also the way Drupal's access system works means that any menu link that points to a node to which the user does not have access, will not be shown for that user. So you won't even have to hide your menu items any more, Drupal will do it for you :)
Regarding Drupal 7 contributed modules, the 'major' modules (Views, CTools, Devel, etc.) are all coming along nicely and are stable, in RC or at least beta. Because Drupal is open source the sole maintainers of smaller modules may not have the time to devote to bringing the Drupal 7 version alongside maintaining the v6 module (a lot of people still use D6 and there are still issues to attend to there).
Personally I've developed quite a number of D7 sites now and have found the contributed modules to be available and of a good quality (for the most part). I guess it just depends what specific functionality you need at the end of the day.
I think there's just a gap between your expectation and how Drupal actually works.
Drupal doesn't limit access to content based on whether or not that content is in the menu. On a site with thousands of nodes it would be overwhelming to have a menu of thousands of items.
Drupal has a rich node access system and there are dozens of modules which can help solve this problem. See the list of content access control modules for ideas on which you might use.
When I run into specific problems with modules I tend to follow a few steps:
re-read the README.txt file and INSTALL.txt file
re-read the project page to see if it links to any further documentation
read the issues for the project to see if any of them have similar descriptions of problems (click on the number links in the right sidebar of the project page)
create a new test site where the only thing I install is the module in question and then walk through the steps I think I should, documenting them in a new issue in the project issue queue as a "support request", and then ending the post with "expected results" and "actual results" - maintainers will usually get back in a few days time
nodeaccess module (http://drupal.org/project/nodeaccess) should work perfectly for you.
I want to let users (i.e. anyone who signs up for an account) upload and download video and text documents. I have been researching the security issues regarding letting users upload files, but everything I can find on the subject assumes that users will only upload images.
Are there any security issues specific to letting users upload videos and text documents? Is security a lot more difficult when users can upload files at video size? Are there any particular file extensions I should look out for?
The problem is this: If you let users upload videos, images and text files, some of them will try to upload viruses, server-side scripts and other malicious code. Such code will then expose your site's users to what ever 'bad things' those users uploaded, within the context of your own site.
If you allow such uploads, you must be very careful that you are only saving files of the actual types you planned on - and not by looking at the file extension, either. You also must make sure those files are placed in locations where execute/script permissions are disabled.
Virus checking is a must - but it is not at all enough. A PHP script may not set off virus warnings at all, but that same script could reveal vital information for your site, or cause other bad things to happen if executed.
You must examine the content of the files - never rely on the extension or MIME type reported by the client. Those can easily be faked.
Serve your downloads from a location for which you have disabled the execution of server side code. This is all you need to do to protect yourself from server side exploits. Relying on file extensions or other such things are all hacks.
If you want to fully protect your users (and indirectly your website) as well, you'll need to run the files through a suitable virus scanner. It is possible, and there are real-life examples of doing so, to exploit video decoders and such software to run arbitrary code. But if you start walking down that line, you could also argue that certain text strings might set off weird behavior in certain software, and that starts getting silly. Luckily, the people who write virus scanners will have done most of the work for you. So:
Never execute that what is uploaded
If you feel it's needed, virus scan them as well.
You can virus check each file that is uploaded. If you look at most web based email clients you will see when you upload a file they are checked by McWhoever. In generally you shouldn't let them upload exe files but checking the extension is a very basic (unreliable) method.
It's quite hard to make an upload REALLY secure.
There are quite a lot of things to check - the file extension is just one part of it. Here are few things which have to be at least checked:
file extension (as you've already mentioned)
mimetype
filesize
depending on the users: maybe check the uploads with ClamAV ...
To answer your question here is a meta attack:
bad guy uploads a binary to your
server, perhaps tricking your
filters by compressing file and
changing extension to .avi
exploit bug in a CGI script to
decompress avi from #1
exploit bug in another CGI to
execute file from #2 -> backdoor
installed
backdoor accessed and rootkit
installed to hide all evidence of steps
1,2,3
Some variation on the above is what typically happens when servers are compromised.
I know this might be a no-brainer, but please read on.
I also know it's generally not considered a good idea, maybe the worst, to let a browser run and interact with local apps, even in an intranet context.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion. These folks are not particularly tech savvy; I don't even consider thinking that they could understand the difference between remote delivered applications and local ones.
So, I've been asked if it's possible. Of course, it is, with IE's good ol' ActiveX controls. And I even made a working prototype (that's where it hurts).
But now, I doubt. Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone? People will use the same browser to surf the web, can I fully trust IE? Isn't there a risk that Microsoft would just disable those controls in future updates/versions? What if a website, or any kind of malware, just put another site on the trust list? With that extent of control, you could as well uninstall every protection and just run amok 'till you got hanged by the IT dept.
I'm about to confront my superiors with the fact that, even if they saw it is doable, it would be a very bad thing. So I'm desperately in need of good and strong arguments, because "let's don't" won't do it.
Of course, if there is nothing to be scared of, that'll be nice too. But I strongly doubt that.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion
I haven't used Citrix very many times, but what's it got to do with executing local applications? I don't see how "People like Citrix" and "browser executing local applications" relate at all?
If the people are accessing your Citrix server from home, and want the same experience in the office, then buy a cheap PC, and run the exact same Citrix software they run on their home computers. Put this computer in the corner and tell them to go use it. They'll be overjoyed.
Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone ? People will use the same browser to surf the web, can I fully trust IE ?
Put it this way. IE has built-in support for AX controls. It uses it's security mechanisms to prevent them from running unless in a trusted site. By default, no sites are trusted at all.
If you use IE at all then you're putting yourself at the mercy of these security mechanisms. Whether or not you tell it to trust the local intranet is beside the point, and isn't going to affect the operation of any other zones.
The good old security holes that require you to reboot your computer every few weeks when MS issues a patch will continue to exist and cause problems, regardless of whether you allow ActiveX in your local intranet.
Isn't there a risk that Microsoft would just disable those controls in future updates / versions ?
Since XP-SP2, Microsoft has been making it increasingly difficult to use ActiveX controls. I don't know how many scary looking warning messages and "This might destroy your computer" dialogs you have to click through these days to get them to run, but it's quite a few. This will only get worse over time.
Microsoft is walking a fine line. On one hand, they regularly send ActiveX killbits with Windows Update to remove/disable applications that have been misbehaving. On the other hand, the latest version of Sharepoint 2007 (can't speak for earlier versions) allows for Office documents to be opened by clicking a link in the browser, and edited in the local application. When the edit is finished, the changes are transmitted back to the server and the webpage (generally) is refreshed. This is only an IE thing, as Firefox will throw up an error message.
I can see the logic behind it, though. Until Microsoft gets all of their apps 'in the cloud', there are cases that need to bridge the gap between the old client-side apps and a more web-centric business environment. While there is likely a non-web workaround, more and more information workers have come to expect that a large portion of their work will be done in a browser. Anything that makes the integration with the desktop easier is not going to be opposed by anyone except the sysadmins.
The standard citrix homepage (or how we use it) is a simple web page with program icons. Click on it, and the application get's delivered to you. People want the same thing, at work, with their applications/folders/documents. And because I'm a web developer, and they asked me, I do it with a web page... Perhaps I should pass the whole thing over to the VB guy..
Ahh... I know of 2 ways to accomplish this:
You can embed internet explorer into an application, and hook into it and intercept certain kinds of URL's and so on
I saw this done a few years ago - a telephony application embedded internet explorer in itself, and loaded some specially formatted webpages.
In the webpage there was this:
Call John Smith
Normally this would be a broken URL, but when the user clicked on this link, the application containing the embedded IE got notified, and proceeded to execute it's own custom code to dial the number from the URL.
You could get your VB guy to write an application which basically just wraps IE, and has handlers for executing applications. You could then code normal webpages with links to just open applications, and the VB app would launch them. This allows you to write your own security stuff (like, only launch applications in a preset list, or so on) into the VB app, and because VB is launching them, not IE, none of the IE security issues will be involved.
The second way is with browser plug-ins.
For example, skype comes with a Firefox plug-in, which looks for phone-numbers in web-pages, and attaches special links to them. When you click on these links it invokes skype - you could conceivably do something similar for launching your citrix apps.
You'd then be tied to firefox though. Writing plugins for IE is much harder than for FF, I wouldn't go down that path unless forced to.