Has Nokia published any documentation on the subject of how to secure
the N800 OS from attack from both a software developer perspective as
well as an end user perspective?
I mention this because, as more Internet aware/dependent applications
are developed for the N800 (it is an Internet tablet after all) the
"attack surface" for the product will increase. I have asked previously
about whether or not the N800 has a stateful firewall but so far the
answer seems to be no.
To provide a context for the question of OS and application security,
here is the url to a www page at the SANS institute Internet Storm
Center www site whose purpose is to provide the viewer with a
perspective on the time between attacks on various kinds of systems:
http://isc.sans.org/survivaltime.html
The data used to collect this information is not country source or
country destination specific thus it represents a reasonable proxy for
what goes on every day on the Internet from wherever one makes a
connection. The idea behind the output graph rendered by this www page
is that, given that
a) your Internet connected system WILL be attacked at
the intervals indicated in the graph ;
then
b) your system will eventually be successfully
compromised unless you do something to prevent that from happening
beforehand.
The "survival time" ; shown in the graph thus attempts to estimate the
time interval between
a) when you connect your system to the Internet
and
b) when your system gets compromised by something, to
be as shown in the graph for the kind of system or app you are using.
I realize that the 770/N800 OS is only a subset of what is possible to
incorporate into a Linux distro and I am sure that the software and
security engineers at Nokia carefully considered the pros and cons of
different OS components/extensions from a security perspective before
deciding whether or not to include them in the Nokia OS200X
distribution. Having said that, ; as this community continues its
excellent work to add functionality to the base system, this question
of OS/stack/app hardening and attack surface minimization becomes a
more important issue to consider. And this does not even consider
vulnerabilities introduced by latent software defects (e.g. not
safely/properly dealing with malformed input), which as this community
knows only too well, can lead to openings for attack. It would be interesting to know what, if
anything,
the Nokia development team has in its OS software product plan
regarding further OS/TCP/IP stack/Application hardening. As more end
users come to depend upon this device to perform sensitive tasks (e.g.
online banking) then this issue will move to the forefront of concern
for those users.
-- Best Regards,
Best
Regards,
John
Holmblad
Re: Security Guidance for N800 OS
development
United States
2007-02-19 11:49:35
ISTR that the "attack surface" rhetoric originates
with Microsoft,
because windows has traditionally had a fairly large one,
and that it
was a good handle for describing "what needs
fixing" on the Microsoft
side. (It has made a big difference there.)
Linux (through it's unix roots) starts off from a better
stance, and
while there are plenty of things to work on, it's not a
matter of
needing to fix everything. (You mention online banking -
the
important issue to linux users there is Phishing and
password
management, *not* packet level attacks, because the user is
(as
always) the weakest link - so, for example, security
labelling in the
Maemo UI might be an interesting topic...)
That said, it would be interesting to see uses of SE/Linux
in embedded
devices like this - but it would *only* be
"interesting", from a
security-geek perspective, it's not going to save the
world...
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
United States
2007-02-19 14:40:41
Dave,
if you think of the N800 simply as an entertainment device then
security is not a significant issue.
However, if and when users start to use this device to store important
and sensitive info whether related to business or personal use then OS
and application security, and especially the latter has to be properly
addressed. It does not matter that the LInux kernel is very secure
because once applications/add-ons (or whatever you want to call them )
which use a protocol stack to get access to the Internet, then there is
a risk that misbehavior of such apps can result in a vulnerability,
especially if the app inadvertently breaks code.
Has Nokia published any documentation on the
subject of how to secure the N800 OS from attack from both a software
developer perspective as well as an end user perspective?
Not that I know of, but I'm not clear what the point would be.
I mention this because, as more Internet
aware/dependent applications are developed for the N800 (it is an
Internet tablet after all) the "attack surface" for the product will
increase. I have asked previously about whether or not the N800 has a
stateful firewall but so far the answer seems to be no.
... because it would be pointless. Anyone opening passive sockets on
such a device really needs so much more than mere firewalling. In
general, I've found firewalling on Linux to be a waste of time if the
idea is to protect the machine itself, even if you do have passive
sockets open. In principle, the layer of software doing the stateful
inspection is essentially the same software doing the processing -
packets arriving which are in the wrong state get discarded *anyway*.
And this does not even consider
vulnerabilities introduced by latent software defects (e.g. not
safely/properly dealing with malformed input), which as this community
knows only too well, can lead to openings for attack.
Well, where's the input coming from? This is typically only a security
problem with multiuser systems or open network services. Malicious
payloads (like, say, email, web pages) can cause issues, but in general
they're much less of a serious issue, and they're certainly no
different to any other platform.
It would be interesting to know what, if
anything, the Nokia development team has in its OS software product
plan regarding further OS/TCP/IP stack/Application hardening. As more
end users come to depend upon this device to perform sensitive tasks
(e.g. online banking) then this issue will move to the forefront of
concern for those users.
I'm just really not clear that this is as much of a big deal as you
seem to think, and I can't see anything specific to Maemo which needs
addressing. If anything, the 770/N800 are a lot more secure than the
average Linux box, let alone the average computer.
Dave.
Re: Security Guidance for N800 OS
development
United Kingdom
2007-02-19 15:00:18
On Mon Feb 19 20:40:41 2007, Acadia Secure Networks wrote:
> Dave,
>
> if you think of the N800 simply as an entertainment
device then
> security is not a significant issue.
>
>
Hmmm... I only recently realized some people do consider it
an
entertainment device.
> However, if and when users start to use this device to
store
> important and sensitive info whether related to
business or
> personal use then OS and application security, and
especially the
> latter has to be properly addressed. It does not matter
that the
> LInux kernel is very secure because once
applications/add-ons (or
> whatever you want to call them ) which use a protocol
stack to get
> access to the Internet, then there is a risk that
misbehavior of
> such apps can result in a vulnerability, especially if
the app
> inadvertently breaks code.
Right, that's a reasonable stance, but I don't see where
Nokia step
in - there's already a huge amount of literature on writing
secure
programs on Linux, and UNIX in general.
If you're running network daemons on the device, you deserve
everything you get, of course, but even then, there's plenty
of
documents and guides.
Dave.
--
Dave Cridland - mailto:davecridland.net - xmpp:dwdjabber.org
-
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
Lithuania
2007-02-20 05:40:09
On Mon, Feb 19, 2007 at 09:00:18PM +0000, Dave Cridland
wrote:
> If you're running network daemons on the device, you
deserve
> everything you get, of course, but even then, there's
plenty of
> documents and guides.
Canola comes with a network daemon. It listens on
127.0.0.1:9000 (the
configuration web server, inaccessible from outside unless
you check
some checkbox) and on port 0.0.0.0:39500 (no idea why, but I
can telnet
to this port from outside).
Also, due to a bug, the X server on the N800 listens on TCP
port 6000:
http
s://maemo.org/bugzilla/show_bug.cgi?id=1055.
I wonder how many people install OpenSSH/Dropbear and then
leave their
root password as the default value (rootme).
Marius Gedminas
--
A bus station is where a bus stops, a train station is where
a train stops. On
my desk I have a work station...
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-20 06:19:56
On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> Also, due to a bug, the X server on the N800 listens on
TCP port 6000:
> http
s://maemo.org/bugzilla/show_bug.cgi?id=1055.
>
> I wonder how many people install OpenSSH/Dropbear and
then leave......
I wonder how many people thrust the openssh deb :p
greetings
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
Lithuania
2007-02-20 08:04:27
On Tue, Feb 20, 2007 at 01:19:56PM +0100, Kees Jongenburger
wrote:
> On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> >Also, due to a bug, the X server on the N800
listens on TCP port 6000:
> >http
s://maemo.org/bugzilla/show_bug.cgi?id=1055.
> >
> >I wonder how many people install OpenSSH/Dropbear
and then leave......
>
> I wonder how many people thrust the openssh deb :p
If you have reasons not to trust it, please elaborate.
Marius Gedminas
--
Microsoft does have a Year 2000 problem. We're it.
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-20 10:53:15
On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> On Tue, Feb 20, 2007 at 01:19:56PM +0100, Kees
Jongenburger wrote:
> > On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> > >Also, due to a bug, the X server on the N800
listens on TCP port 6000:
> > >http
s://maemo.org/bugzilla/show_bug.cgi?id=1055.
> > >
> > >I wonder how many people install
OpenSSH/Dropbear and then leave......
> >
> > I wonder how many people thrust the openssh deb
:p
>
> If you have reasons not to trust it, please elaborate.
Hello Marius, I would feel more comfortable if I knew the
package was built from on a maemo server. Nobody can really
thrust
binary packages anyway. Not only that but we also need to
thrust the
location where the openssh.install file is located. in this
case
http://mg.pov.lt
/770/openssh.install and we need to hope that no other
repository contains a forged openssh pacakge. enough
reasons IMHO to
say that the system is not very secure.
greetings
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
Lithuania
2007-02-20 12:45:08
On Tue, Feb 20, 2007 at 05:53:15PM +0100, Kees Jongenburger
wrote:
> On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> >On Tue, Feb 20, 2007 at 01:19:56PM +0100, Kees
Jongenburger wrote:
> >> On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> >> >I wonder how many people install
OpenSSH/Dropbear and then leave......
> >>
> >> I wonder how many people thrust the openssh
deb :p
> >
> >If you have reasons not to trust it, please
elaborate.
>
> Hello Marius, I would feel more comfortable if I knew
the
> package was built from on a maemo server.
It comes from repository.maemo.org.
> Nobody can really thrust
> binary packages anyway. Not only that but we also need
to thrust the
> location where the openssh.install file is located. in
this case
> http://mg.pov.lt
/770/openssh.install and we need to hope that no other
> repository contains a forged openssh pacakge. enough
reasons IMHO to
> say that the system is not very secure.
That's a good point, but it is not specific to OpenSSH. Any
package you
install on your 770/N800 can add a backdoor.
The solution is package signing. Apt has infrastructure for
that. The
application manager ignores missing signatures, I think.
Also, how do
you decide whose keys to trust?
Marius Gedminas
--
BASIC:
A programming language. Related to certain social
diseases
in that those who have it will not admit it in
polite company.
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-21 14:35:32
On 2/20/07, Marius Gedminas <mariuspov.lt> wrote:
> On Mon, Feb 19, 2007 at 09:00:18PM +0000, Dave Cridland
wrote:
> > If you're running network daemons on the device,
you deserve
> > everything you get, of course, but even then,
there's plenty of
> > documents and guides.
>
> Canola comes with a network daemon. It listens on
127.0.0.1:9000 (the
> configuration web server, inaccessible from outside
unless you check
> some checkbox) and on port 0.0.0.0:39500 (no idea why,
but I can telnet
> to this port from outside).
Just to be clear:
- canola-conf listen to 127.0.0.1:9000 (can be changed
using
GConf), it's a webserver that serves HTML, JS, ... it's
written using
libsoup and actions (/actions/ClassName/{get,set}_data and
/actions/ClassName/get_presentation) is written in C, for
objects that
implement CnlIConfigure interface, so far I wrote them all.
I'm still
not aware of any buffer overflow that could compromise the
device.
Worth remembering that it runs as "user", not
root.
- canola listen to 0.0.0.0:39500 (tcp), 0.0.0.0:39400
and
0.0.0.0:1900 (udp) due CLinkC/UPnP library, it's provided by
Nokia and
also used by Media Streamer.
Canola-Conf is started at boot time and can be started using
DBus
activation by Canola or Applet, it stay up and running
(actually,
sleeping) all the time, monitoring MMC using GnomeVFS and
doing rescan
when something changes. It also serves as webserver as
explained
above.
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbierigmail.com
MSN: barbierigmail.com
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; 08122692sip.stanaphone.com
GPG: 0xB640E1A2 wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-22 08:19:06
On 2/22/07, Eero Tamminen <eero.tamminennokia.com> wrote:
> Hi,
>
> ext Gustavo Sverzut Barbieri wrote:
> > - canola-conf listen to 127.0.0.1:9000 (can be
changed using
> > GConf), it's a webserver that serves HTML, JS, ...
it's written using
> > libsoup and actions
(/actions/ClassName/{get,set}_data and
> > /actions/ClassName/get_presentation) is written in
C, for objects that
> > implement CnlIConfigure interface, so far I wrote
them all. I'm still
> > not aware of any buffer overflow that could
compromise the device.
> > Worth remembering that it runs as
"user", not root.
>
> "user" user can do anything in the device
that the device owner can
> through the the device UI, so in practice this does
*not* prevent
> compromised process from doing _anything_ that
matters.
>
> To be more secure:
> - run the process e.g. as user "nobody", this
way it cannot
> ruin user's settings, files, install other SW
(through sudo) etc
we need exactly to access user file /home/user/.canola/* and
his gconf
options :-/
> - nice the process, so that it cannot take all the CPU
> - use ulimit so that the process memory usage is
limited more
> than user application's, otherwise it may be able to
get
> some of user's apps to abort when memory runs low
> - AFAIK kernel OOM-handler should be able to handle
fork-bombs too
that's something to be considered.
> - chroot it to its work directory, so that it cannot
read
> anything outside it
you need root access to have that.
> With this it can still fill the Flash which might
require user
> to reflash the device (unless he's a Linux developer
who knows
> how to eliminate the offending the program and find
what is taking
> all the Flash). Ulimit has a setting for limiting the
file sizes,
> but I'm not sure whether that's enough to prevent
process from
> filling the device Flash.
We have no reports on it consuming much file space. 770
version uses
sqlite0, which may need vaccuum that we don't do, but even
without it,
db doesn't grow that big.
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbierigmail.com
MSN: barbierigmail.com
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; 08122692sip.stanaphone.com
GPG: 0xB640E1A2 wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-22 09:18:06
Hi,
ext Gustavo Sverzut Barbieri wrote:
>> > - canola-conf listen to 127.0.0.1:9000 (can
be changed using
>> > GConf), it's a webserver that serves HTML, JS,
... it's written using
>> > libsoup and actions
(/actions/ClassName/{get,set}_data and
>> > /actions/ClassName/get_presentation) is
written in C, for objects that
>> > implement CnlIConfigure interface, so far I
wrote them all. I'm still
>> > not aware of any buffer overflow that could
compromise the device.
>> > Worth remembering that it runs as
"user", not root.
>>
>> "user" user can do anything in the device
that the device owner can
>> through the the device UI, so in practice this does
*not* prevent
>> compromised process from doing _anything_ that
matters.
>>
>> To be more secure:
>> - run the process e.g. as user "nobody",
this way it cannot
>> ruin user's settings, files, install other SW
(through sudo) etc
>
> we need exactly to access user file
/home/user/.canola/* and his gconf
> options :-/
With user nobody, it would still be able to read the files
(depending on
the file rights), but that would be very kludgy. Reading
the gconf
options shouldn't(?) be a problem I think as the process
needs only to
be able to connect to the D-BUS.
>> - nice the process, so that it cannot take all the
CPU
>> - use ulimit so that the process memory usage is
limited more
>> than user application's, otherwise it may be
able to get
>> some of user's apps to abort when memory runs
low
>> - AFAIK kernel OOM-handler should be able to
handle fork-bombs too
>
> that's something to be considered.
IMHO all background services which response time is not
crucial should
be at least niced, especially if they handle data that can
come from
outside the device. (metalayer-crawler is a good example of
why )
>> - chroot it to its work directory, so that it
cannot read
>> anything outside it
>
> you need root access to have that.
Yes, it's a bit extreme, used maybe as the last step...
>> With this it can still fill the Flash which might
require user
>> to reflash the device (unless he's a Linux
developer who knows
>> how to eliminate the offending the program and find
what is taking
>> all the Flash). Ulimit has a setting for limiting
the file sizes,
>> but I'm not sure whether that's enough to prevent
process from
>> filling the device Flash.
>
> We have no reports on it consuming much file space. 770
version uses
> sqlite0, which may need vaccuum that we don't do, but
even without it,
> db doesn't grow that big.
Wasn't the question about protecting against something that
compromises
the server through its network socket and tries explicitly
to
harm/exploit the device?
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-22 09:20:04
On 2/22/07, Eero Tamminen <eero.tamminennokia.com> wrote:
> Hi,
>
> ext Gustavo Sverzut Barbieri wrote:
> >> > - canola-conf listen to 127.0.0.1:9000
(can be changed using
> >> > GConf), it's a webserver that serves
HTML, JS, ... it's written using
> >> > libsoup and actions
(/actions/ClassName/{get,set}_data and
> >> > /actions/ClassName/get_presentation) is
written in C, for objects that
> >> > implement CnlIConfigure interface, so far
I wrote them all. I'm still
> >> > not aware of any buffer overflow that
could compromise the device.
> >> > Worth remembering that it runs as
"user", not root.
> >>
> >> "user" user can do anything in the
device that the device owner can
> >> through the the device UI, so in practice this
does *not* prevent
> >> compromised process from doing _anything_ that
matters.
> >>
> >> To be more secure:
> >> - run the process e.g. as user
"nobody", this way it cannot
> >> ruin user's settings, files, install other
SW (through sudo) etc
> >
> > we need exactly to access user file
/home/user/.canola/* and his gconf
> > options :-/
>
> With user nobody, it would still be able to read the
files (depending on
> the file rights), but that would be very kludgy.
Reading the gconf
> options shouldn't(?) be a problem I think as the
process needs only to
> be able to connect to the D-BUS.
>
>
> >> - nice the process, so that it cannot take all
the CPU
> >> - use ulimit so that the process memory usage
is limited more
> >> than user application's, otherwise it may
be able to get
> >> some of user's apps to abort when memory
runs low
> >> - AFAIK kernel OOM-handler should be able
to handle fork-bombs too
> >
> > that's something to be considered.
>
> IMHO all background services which response time is not
crucial should
> be at least niced, especially if they handle data that
can come from
> outside the device. (metalayer-crawler is a good
example of why )
>
>
> >> - chroot it to its work directory, so that it
cannot read
> >> anything outside it
> >
> > you need root access to have that.
>
> Yes, it's a bit extreme, used maybe as the last
step...
>
>
> >> With this it can still fill the Flash which
might require user
> >> to reflash the device (unless he's a Linux
developer who knows
> >> how to eliminate the offending the program and
find what is taking
> >> all the Flash). Ulimit has a setting for
limiting the file sizes,
> >> but I'm not sure whether that's enough to
prevent process from
> >> filling the device Flash.
> >
> > We have no reports on it consuming much file
space. 770 version uses
> > sqlite0, which may need vaccuum that we don't do,
but even without it,
> > db doesn't grow that big.
>
> Wasn't the question about protecting against something
that compromises
> the server through its network socket and tries
explicitly to
> harm/exploit the device?
yes, but the most harmful action is to add "/" to
be scanned, but
that's in blacklist so it's avoided.
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbierigmail.com
MSN: barbierigmail.com
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; 08122692sip.stanaphone.com
GPG: 0xB640E1A2 wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-22 09:27:18
Hi,
ext Gustavo Sverzut Barbieri wrote:
> yes, but the most harmful action is to add
"/" to be scanned, but
> that's in blacklist so it's avoided.
If it is monitoring file changes in the device, you should
also
ignore at least /dev & /sys*, otherwise your process
wakes up
unnecessarily (which drains battery).
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS
development
2007-02-22 17:20:53
On 2/22/07, Eero Tamminen <eero.tamminennokia.com> wrote:
> Hi,
>
> ext Gustavo Sverzut Barbieri wrote:
> > yes, but the most harmful action is to add
"/" to be scanned, but
> > that's in blacklist so it's avoided.
>
> If it is monitoring file changes in the device, you
should also
> ignore at least /dev & /sys*, otherwise your
process wakes up
> unnecessarily (which drains battery).
Sure, we ignore:
static const gchar *blacklist[] = {
"/bin",
"/boot",
"/dev",
"/etc",
"/lib",
"/proc",
"/root",
"/sbin",
"/sys",
"/usr/bin",
"/usr/sbin",
"/usr/etc",
"/usr/lib",
NULL
};
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbierigmail.com
MSN: barbierigmail.com
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; 08122692sip.stanaphone.com
GPG: 0xB640E1A2 wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Monitoring file updates (was:
Security Guidance for N800 OS
development)
2007-02-23 01:58:48
Hi,
ext Gustavo Sverzut Barbieri wrote:
>> > yes, but the most harmful action is to add
"/" to be scanned, but
>> > that's in blacklist so it's avoided.
>>
>> If it is monitoring file changes in the device, you
should also
>> ignore at least /dev & /sys*, otherwise your
process wakes up
>> unnecessarily (which drains battery).
>
> Sure, we ignore:
>
> static const gchar *blacklist[] = {
> "/bin",
> "/boot",
> "/dev",
> "/etc",
> "/lib",
> "/proc",
> "/root",
> "/sbin",
> "/sys",
> "/usr/bin",
> "/usr/sbin",
> "/usr/etc",
> "/usr/lib",
> NULL
> };
Any particular reason why you're not ignoring
"/var" (where can
be log files etc) and "/tmp" (where are locks,
sockets and app state
data etc) which get often updated?
Btw. As a general security rule (this is not about security
but..),
it's better to allow things that are known to be safe and
ignore
rest than try to deny things (because that way you will
always miss
some new exploits).
If the server is interested only about media files, it's
better to
allow only stuff under /home and /media. And if you're
checking
stuff under /media, you SHOULD be promptly reacting to
unmount
messages[1] for the media cards. I've gotten some
(unconfirmed)
doubts that if something is blocking memory card unmounting
and it
needs to be forced (e.g. at shutdown), that sometimes might
corrupt
the FAT[2] filesystem on users' memory cards.
[1] Gconf key updates for:
- /system/osso/af/mmc-cover-open
- /system/osso/af/usb-cable-attached
- /system/osso/af/internal-mmc-cover-open
[1] Microsoft in 80's didn't really "design" FAT
to be robust...
And as can be learned from the issues with
metalayer-crawler,
inserting a memory card with corrupted FAT can create some
interesting problems unless developer takes extra pains to
handle error cases like:
- infinitely recursing directories and this doesn't mean
just ignoring
(directory) symlinks, but actual (corrupted MMC FAT)
filesystem
directories being recursive
- errors on allocations and with directory/file reads *and*
reacting
correctly to them i.e. not retrying (at least more than
couple of
times), but canceling/unwinding (suitable part of) the
operation
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
Re: Monitoring file updates (was:
Security Guidance for N800 OS
development)
2007-02-24 18:03:54
On 2/23/07, Eero Tamminen <eero.tamminennokia.com> wrote:
> Hi,
>
> ext Gustavo Sverzut Barbieri wrote:
> >> > yes, but the most harmful action is to
add "/" to be scanned, but
> >> > that's in blacklist so it's avoided.
> >>
> >> If it is monitoring file changes in the
device, you should also
> >> ignore at least /dev & /sys*, otherwise
your process wakes up
> >> unnecessarily (which drains battery).
> >
> > Sure, we ignore:
> >
> > static const gchar *blacklist[] = {
> > "/bin",
> > "/boot",
> > "/dev",
> > "/etc",
> > "/lib",
> > "/proc",
> > "/root",
> > "/sbin",
> > "/sys",
> > "/usr/bin",
> > "/usr/sbin",
> > "/usr/etc",
> > "/usr/lib",
> > NULL
> > };
>
> Any particular reason why you're not ignoring
"/var" (where can
> be log files etc) and "/tmp" (where are
locks, sockets and app state
> data etc) which get often updated?
I've replyied in another mail, but here it goes: some users
may have
maemo on MMC/SD and media under /var/media or /var/lib...
but ok, it's
a rare case. I'll make this blacklist came from GConf,
pre-defined
with /tmp, /var and others except /home and /media
> Btw. As a general security rule (this is not about
security but..),
> it's better to allow things that are known to be safe
and ignore
> rest than try to deny things (because that way you will
always miss
> some new exploits).
It's kinda hard to implement whiltelist for end-user (or not
security
aware user) applications. Users tend to want things their
ways, you
cannot force them and tell our way is right, just check
https://garage.maemo.org/
tracker/?func=detail&atid=529&aid=499&group_id=1
25
Anyway, it's a blacklist to let user choose his whitelist...
We just
scan what user choose.
> If the server is interested only about media files,
it's better to
> allow only stuff under /home and /media. And if you're
checking
> stuff under /media, you SHOULD be promptly reacting to
unmount
> messages[1] for the media cards. I've gotten some
(unconfirmed)
> doubts that if something is blocking memory card
unmounting and it
> needs to be forced (e.g. at shutdown), that sometimes
might corrupt
> the FAT[2] filesystem on users' memory cards.
>
> [1] Gconf key updates for:
> - /system/osso/af/mmc-cover-open
> - /system/osso/af/usb-cable-attached
> - /system/osso/af/internal-mmc-cover-open
Actually we listen for GnomeVFS DBus events: mount, unmount
and pre-unmount.
pre-unmount is used to let us copy canola.db to it before
it's
unmounted. It's used to let PC applications like syncropated
to
configure existing DB (it read from existing tables and then
store SQL
queries on backlog table, that will be executed by canola,
not used so
far).
So, canola-conf can cause problems while copying canola.db,
but just
if user force removal, since filesystem isn't unmounted if
there are
open files.
> [1] Microsoft in 80's didn't really "design"
FAT to be robust...
>
>
> And as can be learned from the issues with
metalayer-crawler,
> inserting a memory card with corrupted FAT can create
some
> interesting problems unless developer takes extra pains
to
> handle error cases like:
> - infinitely recursing directories and this doesn't
mean just ignoring
> (directory) symlinks, but actual (corrupted MMC FAT)
filesystem
> directories being recursive
> - errors on allocations and with directory/file reads
*and* reacting
> correctly to them i.e. not retrying (at least more
than couple of
> times), but canceling/unwinding (suitable part of)
the operation
Yeah, we've experienced some, but most were due using SWAP
on MMC.
Anyway, N800 should reduce these problems and copy of
canola.db to mmc
may vanish if required.
Thanks for feedback!
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbierigmail.com
MSN: barbierigmail.com
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; 08122692sip.stanaphone.com
GPG: 0xB640E1A2 wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers
maemo.org
)
>> - chroot it to its work directory, so that it
cannot read
>> anything outside it
>
> you need root access to have that.
Yes, it's a bit extreme, used maybe as the last step...
>> With this it can still fill the Flash which might
require user
>> to reflash the device (unless he's a Linux
developer who knows
>> how to eliminate the offending the program and find
what is taking
>> all the Flash). Ulimit has a setting for limiting
the file sizes,
>> but I'm not sure whether that's enough to prevent
process from
>> filling the device Flash.
>
> We have no reports on it consuming much file space. 770
version uses
> sqlite0, which may need vaccuum that we don't do, but
even without it,
> db doesn't grow that big.
Wasn't the question about protecting against something that
compromises
the server through its network socket and tries explicitly
to
harm/exploit the device?
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers