It does? Correct me if I'm wrong (I've never used Android), but as far as I know, Android just lists all the permissions the app wants, and you have to agree to all of them before you can start the app. If you want to deny a specific permission, you're out of luck.
iOS admittedly lacked such a permission system for a long time, but since iOS6 it has fine-grained control - you can selectively allow or deny an app to access: - Location services - Contacts - Calendars - Reminders - Photos - Bluetooth sharing - Twitter - Facebook
IIRC, before iOS6 apps only had to ask for the Location services permission. Since iOS6 all these permissions should be disabled by default, and the app has to ask you before it can access the respective service.
c:\> findstr/? [...] /R Uses search strings as regular expressions.
But findstr is no sed replacement - it can't do search and replace as far as I know.
Also if you're using/R you'll most probably also want to use/C, or findstr will split the string at every space into multiple regexes. I found that very confusing when I used findstr/R for the first time.
My company supports about 700 Debian servers that are running at customer sites; as far as I can tell, not a single one of these has been compromised due to an unpatched security vulnerability in one of the Debian packages. Configure some kind of auto-update (e.g. cron-apt); Debian is by default configured to only install security updates and these are usually released within one or two days.
We did have a few servers that were compromised due to customer mistakes (unsafe root passwords especially) though. From what I've learned in these incidents, you can spot an infected machine by these symptoms:
apt installations are failing with strange errors. Rootkits often replace core utilites like ls with simpler versions that don't support the GNU extensions, and this causes many programs to visibly break.
rkhunter output
debsums -s output
duplicate uid 0 (grep in/etc/passwd)
folders that begin with a . in strange places like in/usr
folders that have names like ".. "
In theory, a rootkit could be hidden really well, but in practice, the attackers just don't seem to care to adapt their rootkits specifically to the distros. An experienced Linux admin should have no problem detecting them.
android has better privacy controls than iOS.
It does? Correct me if I'm wrong (I've never used Android), but as far as I know, Android just lists all the permissions the app wants, and you have to agree to all of them before you can start the app. If you want to deny a specific permission, you're out of luck.
iOS admittedly lacked such a permission system for a long time, but since iOS6 it has fine-grained control - you can selectively allow or deny an app to access:
- Location services
- Contacts
- Calendars
- Reminders
- Photos
- Bluetooth sharing
- Twitter
- Facebook
IIRC, before iOS6 apps only had to ask for the Location services permission. Since iOS6 all these permissions should be disabled by default, and the app has to ask you before it can access the respective service.
c:\> findstr /?
/R Uses search strings as regular expressions.
[...]
But findstr is no sed replacement - it can't do search and replace as far as I know.
Also if you're using /R you'll most probably also want to use /C, or findstr will split the string at every space into multiple regexes. I found that very confusing when I used findstr /R for the first time.
My company supports about 700 Debian servers that are running at customer sites; as far as I can tell, not a single one of these has been compromised due to an unpatched security vulnerability in one of the Debian packages. Configure some kind of auto-update (e.g. cron-apt); Debian is by default configured to only install security updates and these are usually released within one or two days.
We did have a few servers that were compromised due to customer mistakes (unsafe root passwords especially) though. From what I've learned in these incidents, you can spot an infected machine by these symptoms:
In theory, a rootkit could be hidden really well, but in practice, the attackers just don't seem to care to adapt their rootkits specifically to the distros. An experienced Linux admin should have no problem detecting them.