Root CA Certificate

[pseudonym404]

Is there any way at all to get a self-signed code signing root ca certificate on s60v3 devices?

I simply want this for my own phone (N95), for personal use only, I'm quite happy to distribute normal self signed packages in most instances (even tolerate the excruciating symbian signed freeware process if necessary), but it's a pretty sorry state of affairs if I can't trust myself....

On the subject of symbian signing, I've just sent my second account request email...

[cdavies]

Not really. This is what dev certs are for.

[pseudonym404]

Which would be a start if I could get a symbian signed account...

I realise that of course symbian signed are under no obligation to grant extended/platform/manufacturer capabilities, but I feel strongly that the owner of a device should be able to grant themselves these capabilities on their own device (the AllFiles/TCB one sticks out with a lot of people, there's definately something wrong with another entity having write access to storage I own, that I can't even read).

[cdavies]

Well, as most know, I'm not a big fan of Symbian Signed. I think the implementation is a colossal mistake, but the principle is sound enough.

Capabilities like TCB must be tightly controlled, for the security of the platform as a whole. Even within Symbian and the manufacturers, processes just can't have TCB, it's forbidden. Every extra line of code that runs with TCB is an extra line of code that needs security auditing. The trusted computing base must be just that, trusted.

Ditto DRM, allowing people to make any process they like with the DRM capability means that companies like Nokia would be exposed to liabilities in the multi-million dollar range. While I don't necessarily agree with the use of DRM, in as far as it restricts the legal rights of consumers, it seems to be a present commercial reality, and that relies on there being things on your own phone that you yourself cannot read. Don't be fooled, any other phone platforms, and most desktop PCs do the same thing, they just aren't us up front about it, and rely far more on obscurity.

By and large, there's nothing you'll ever need to do on your phone that you'll need All Files or TCB for. I've yet to see anyone on these forums or off make even a weak business case for having either capability (with the exception of certain device drivers, which isn't really the same thing...)

If you need any of the other manufacturer granted capabilities for your apps, just apply for them. More often than not your application will be granted. Mine was.

Sorry that you haven't yet got a Symbian Signed account, but that's mainly due to massive incompetence. Whether on the part of the Symbian team or Cidercone, I can scarcely dare venture an opinion. At this point, I would suggest you email Symbian's CEO Nigel Clifford direct, you can figure out his email address easily enough.

[pseudonym404]

Well, as most know, I'm not a big fan of Symbian Signed. I think the implementation is a colossal mistake, but the principle is sound enough.

I'm inclined to agree, I've been quite happy using various ACLs (usually selinux) in various Linux distros, of course the key point is that there, I can change the policy on my computer if I find it too restrictive.

Capabilities like TCB must be tightly controlled, for the security of the platform as a whole. Even within Symbian and the manufacturers, processes just can't have TCB, it's forbidden. Every extra line of code that runs with TCB is an extra line of code that needs security auditing. The trusted computing base must be just that, trusted.

Which makes complete sense from a distribution point of view, and a lot of sense on your own device; of course if you don't need global filesystem read/write, don't allow it. My only problem is that this isn't my decision on my device.

Ditto DRM, allowing people to make any process they like with the DRM capability means that companies like Nokia would be exposed to liabilities in the multi-million dollar range. While I don't necessarily agree with the use of DRM, in as far as it restricts the legal rights of consumers, it seems to be a present commercial reality, and that relies on there being things on your own phone that you yourself cannot read. Don't be fooled, any other phone platforms, and most desktop PCs do the same thing, they just aren't us up front about it, and rely far more on obscurity.

I definately don't agree with the use of DRM, for the same reason, and would be quite happy without DRM code on my phone, although I'm happy to ignore the commercial reality in this case as far as it concerns me not being able to access DRM code I don't use and have no interest in.

As an aside, I'm currently running Kubuntu on an amd64, and with the exception of the 'restricted modules' package (I have an nVidia graphics card) and several of the symbian toolchain exes (run under wine), the source code for all binaries on the system is available. None of which is strictly relevant, other than to say I'm used to a very open development environment.

By and large, there's nothing you'll ever need to do on your phone that you'll need All Files or TCB for. I've yet to see anyone on these forums or off make even a weak business case for having either capability (with the exception of certain device drivers, which isn't really the same thing...)

I'd agree, the problem is, this is by and large, rather than never, and again it's not my decision on my device. For instance, one project idea I quite like is a port of bash using OpenC (and therefore of course an ncurses port and a symbian c++ terminal emualator), I appreciate the business case would be pretty weak (I'd find a shell quite useful though), but this isn't my motivation, I simply like the idea.

If you need any of the other manufacturer granted capabilities for your apps, just apply for them. More often than not your application will be granted. Mine was.

Which again, I don't have any qualms with for distribution purposes (even if it does (reputedly) take so long for the freeware process), but I'm sticking to the 'on my device' thing.

Sorry that you haven't yet got a Symbian Signed account, but that's mainly due to massive incompetence. Whether on the part of the Symbian team or Cidercone, I can scarcely dare venture an opinion. At this point, I would suggest you email Symbian's CEO Nigel Clifford direct, you can figure out his email address easily enough.

Thanks, I'll try that.

[cdavies]

Even in your Linux machine, not everything is open, and for good reason.

If you use firefox for browsing, you'll probably have some passwords saved. Go to the .firefox directory and try and get the plaintext of those passwords. It's difficult. Not impossible, because they're obscure rather than secure, but it's still difficult. Of course, that stops you from easily accessing the passwords if you forget them, but perhaps that's a small price to pay for not allowing others to get at them either. I don't think anyone would argue that those should be written to disk as plaintext, or that there should be a configuration option to control that behaviour. They're also in your home directory, which prevents people logged on as other users accessing them. The Linux security model's equivalent of Symbian's private directories.

I recognise that not everything about platsec is to your advantage, some of it is used to screw you out of rights you would otherwise have ("DRM".) But overwhelmingly, platsec is a good thing for both users and application authors.

As for your example of a terminal emulator, you don't need any manufacturer granted capabilities to do that. I don't think you need any capabilities to do that in fact, even user granted ones.

[pseudonym404]

Yes, but that's just comparing security models, my key point is that on my Linux system, I can control the degree of openness. For the firefox example, I certainly wouldn't argue that stored passwords should be written to disk as plaintext, but nevertheless, they could be. Or with selinux for example, I can decide that process foo does infact require write access to /bar, at no point having to defer to the Linux distributor for permission to do so.

I don't think a terminal emulator would need any capabilities either, but I think bash would need read access to c:\sys\bin.

[cdavies]

I don't see why bash would need read access to /sys/bin... If you want to run a process, the loader does the reading for you.

[pseudonym404]

How would you find out what's available in /sys/bin to execute though?

[cdavies]

By chucking the command line the user types at RProcess::Create, like the unix version does with execve, I suppose.

[pseudonym404]

I was working on the assumption that /sys/bin would be in the path, although given that executables must be in /sys/bin, this could be mostly worked around. Is there any way of checking if an executable exists in /sys/bin prior to trying to execute it without read access?

[cdavies]

To what end? You just do RProcess::Create, and if it says the executable doesn't exist, it doesn't exist.

[pseudonym404]

bash will expect to be able to get a listing for directories in the path, although as I said, this could be mostly worked around (perhaps by using wrapper file system calls that refer to a cache of any executables 'found' by executing them directly), remembering that the path may include multiple directories (scripts wouldn't have to be in /sys/bin). This just seems like an excessive workaround to not being able to get a directory listing in the first place.

Perhaps it would be better if the filesystem was mostly navigable without capabilities, and the capabilites only restricted read/write of files and the creation of files/folders. Maybe even make that level of access a separate capability.

Anyway, I digress. Thankyou for your help, I will persist in my attempts to obtain a symbian signed account.